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(57) Abstract 

Methods and apparatus which deal with the 
management of risk relating to specified, yet un- 
known, future events are disclosed. "Sponsor" 
stakeholders (12) specify a particular product relat- 
ing to an event or phenomenon for which there is 
a range of possible future outcomes. "Ordering" 
stakeholders (13) then offer contracts relating to 
the predetermined phenomenon and corresponding 
range of outcomes, The offered contracts specify an 
entitlement (or pay-oil) at the future time of matu- 
rity for each outcome, and a consideration (or pre- 
mium) payable, in exchange, to a "counter-party" 
stakeholder (14). Independently of the offered con- 
tracts, the "counter-party" stakeholders (14) input 
data as to their view of the Hkelihood of occurrence 
of each outcome in the predetermined range into 
the future, or specifically at the predetermined date 
of maturity. Each offered contract is priced by the 
processing units (20) by «*imU>tiiig counter-party 
premiums from the registered data, and a match at- 
tempted by a comparison of the offered premium 
with the calcnlatnd premiums. Matched contracts 
can be further traded until maturity, and at-maturity 
processing han dles the exchange of entitlement as 
between the rnatrrrnd patties to the contract, 
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Methods and App aratus Relating to the Formulation 
and Trading of Risk Management Contracts . 

TECHNICAL FIELD 

5 This invention relates to methods and apparatus, Including 

electrical computers and data processing systems applied to financial 
matters and risk management. In particular, the Invention Is concerned 
with the management of risk relating to specified, yet unknown, future 
events. 

10 

BACKGROUND ART 

Individuals and enterprises are continually exposed to risk 
because of future events beyond their control. The outcome of those 
events can either positively or negatively impact on their wellbelng. 

15 Individuals and enterprises should generally prefer not to face exposure 
to the possibility of adverse consequences, regardless of their 
perception of the likelihood of such events occurring^ It Is 1r their 
interest to consider foregoing Resources 1 they currently possess If 
doing so would reduce the possibility of being so greatly exposed to 

20 future outcomes. 

Risk can take many forms 1n view of the large range and type of 
future events which might result 1n adverse consequences. Risk can be 
categorised, 1n one Instance, as 'economic 1 In nature. Phenomena that 
constitute economic risk Include: commodity prices, currency exchange 

25 rates, Interest rates, property prices, share prices, Inflation rates, 
company performance, and market event based Indices. 

Another characterisation of risk concerns 'technical 1 phenomena. 
This can Include things like the breakdown of an electricity generation 
plant, aircraft engine failure, and the damage to, or failure of, 

30 orbiting telecommunications satellites. The outcomes for each of these 
phenomena will be adverse for the users and/or supplier* 

Other forms of risk defy ready characterisation, such as 
weather-based (viz., rain damage or lightning strike), or other natural 
occurrences (viz., earthquakes or Iceberg collision with sea-going 

35 vessels). 

There are also less tangible risks associated with, for example, 
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the emission of atmospheric pollutants or the disposal of Intractable 
toxic wastes, 1n the sense that the future consequences .are. unknown, 
save that there Is a notion, based on current Information, that they 
could be adverse. 

5 The capability to manage risk Is more Important today than 1t was 

1n the past, and Is likely to become ever-more Important into the 
future, because there is an ever Increasing exposure to a wider generic 
range of future phenomena beyond the control of individuals or 
enterprises. There is also a wider feasible range of possible future 

10 events, and greater uncertainty about the likelihood of occurrence, 
associated with any single future phenomenon viz., an increasing 
volatility. 

It is also thought that Individuals are now more risk-averse 1n 
recessionary times, when there are fewer available discretionary 
15 resources to trade-off to protect themselves from such adverse future 
events. 

In the prior art, individuals and enterprises faced with 
'technical' risk have hedged against future outcomes by mechanisms such 
as the adoption of quality assurance practices, warranties, increased 

20 research and development activity (and associated Intellectual property 
rights such as patents, utility models and registered designs), the 
purchase of modernised plant and equipment, and improved inventory, 
occupational health and safety and employer /employee relations practices. 
Consider a manufacturer of, say, Integrated circuits (ICs), which 

25 has many clients wishing to purchase its ICs. The demand may result 1n 
a delay 1n delivery due to limited manufacturing capacity, thereby 
requiring advance production scheduling for orders already in-hand. 
Typically, the manufacturer will give a warranty to a purchaser as to 
measurable performance criteria for its ICs; 1f a batch does not perform 

30 to the specified criteria, the manufacturer 1s required by contract to 
replace that batch. That is, a purchaser may have no interest in 
obtaining monetary compensation for the poor quality ICs, as the 
purchaser needs the components for their own products. In that case, 
the 'consideration* the warranty makes is the priority scheduling of a 

35 substitute batch of that type of IC, possibly displacing other scheduled 
production runs, or deferring delivery to another purchaser. 
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Such contractual arrangements are piece-meal In nature, and can 
only be struck between the manufacturer and each Individual . purchaser. 
They also leave the manufacturer exposed to claims from other customers 
whose orders are delayed by the re-scheduling. The manufacturer has no 

5 convenient mechanism available to It to hedge against such claims, 

perhaps by way of reserving production rights with another manufacturer, 
In lieu of unavailability of their own manufacturing facility. 

In the face of such 'economic 1 risk, it 1s known for Individuals 
and enterprises to hedge against adverse outcomes by Indirect means such 

10 as self-insurance, and directly by means such as futures contracts, 
forward contracts, and swaps. 

There are disadvantages or limitations associated with such 
available economic risk management mechanisms. Particularly, they 
provide, at best, only indirect approaches to dealing with the risk 

15 management needs. The available mechanisms are relatively expensive, 
and provide limited phenomenon coverage, and therefore cannot meet the 
requirements of the party seeking to hedge against such wide-ranging 
future risk. The infrastructure and pay-out costs associated with 
switching between, say, a commodities market and a stock market are 

20 often prohibitive for entitles small and large allkel As a consequence, 
entitles find themselves saddled with obligations they have little 
control over and cannot escape. 

In respect of the "less tangible" forms of risk, an example 1n the 
prior art of a form of management of that risk 1s that of 'pollution 

25 rights' sold by the U.S. Environmental Protection Agency (EPA) In March 
1993 for the atmospheric emission of sulphur dioxide. This was done by 
an auction of "allowances" permitting the release Into the atmosphere. 
By the year 1995, any company or organisation emitting sulphur dioxide 
In the U.S. without enough allowances to cover their total emissions 

30 will face prosecution. This means polluters must either buy further 
allowances, or else modify or replace their plant and equipment to 
reduce these emissions. The EPA will regulate the total number of 
allowances able to be obtained. The existing allowances have already 
become a valuable tradeable 'property' as between sulphur dioxide 

35 emitters, that Is, even before the time when no further allowances will 
be able to be purchased. 
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Management techniques for the "less tangible" forms of risk are In 
their Infancy. The existing forms Indicate an emerging demand for 
systems and methods to enable effective management. 

Specific examples In the prior art of patents relating to methods 

5 and apparatus which deal with various forms of risk management Include 
British Patent No. 2 180 380, In the name of Merrill Lynch Pierce Fenner 
and Smith Incorporated, directed to an Automated Securities Trading 
Apparatus (corresponding to U.S. Patent No. 4,674,004, and further 
related to U.S. Patents No. 4,346,442 and 4,376,978). Other examples 

10 'include U.S. Patent No. 4,739,478 assigned to Lazard Freres and Co., 
directed to Methods and Apparatus for Restructuring Debt Obligations, 
U.S. Patent No. 4,751,640 assigned to Citibank, N.A., directed to An 
Automated Investment System, and U.S. Patents No. 4,752,877, 4,722,055, 
and 4,839,804 assigned to College Savings Bank directed to Methods and 

15 Apparatus for Funding Future Liability of Uncertain Cost. 

The present invention comes about 1n view of the shortcomings of 
existing risk management mechanisms, and the perceived increasing 
Importance of the management of risk relating to specified, yet unknown, 
future events. 

20 In this sense, the Invention Is directed to something having 

economic value to individuals, enterprises and societies as a whole. 
Methods and apparatus that provide for the management of risk offer 
material advantages by, for example, minimising adverse future outcomes, 
providing both a form of compensation In the event of adverse future 

25 outcomes, and forms of risk management not otherwise supported or 

available In the prior art, and thus have value In the field of economic 
endeavour. 

DISCLOSURE QF THE INVENTION 
30 The Invention encompasses methods and apparatus enabling the 

management of risk relating to specified, yet unknown, future events by 

enabling entities (parties) to reduce their exposure to specified risks 

by constructing compensatory claim contract orders on 

yet- to-be-1 dentlfl ed counter-parties, being contingent on the occurrence 
35 of the specified future events. The entitles submit such orders to a 

'system 1 which seeks to price and match the most appropriate 
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counter-party, whereupon matched contracts are appropriately processed 
through to their maturity. 

Therefore, the invention enables parties to manage perceived risk 
In respect of known, yet non-predictable, possible future events. These 

5 future events may relate to measurable phenomena whose outcome 1s 
verifiable, and cannot be materially Influenced by any other entity 
having a stake 1n that outcome. 

The ability to price and match risk aversion contracts essentially 
comes about because of the nature of risk Itself. Any number of people 

10 will each have differing views as to the likelihood of an outcome of 
some future event. This means that when each person Is required to 
Independently assess a range of outcomes for a specified future date, 
there almost always will be a variance 1n those assessments. Thus 1t 1s 
possible to match these expectations as between parties to form a 

15 contract. The potential counter-parties to an offered contract have the 
motivation of taking up an opportunity to exploit differing views of 
future outcomes to their advantage, either for some gain or, again, as a 
form of risk management. 

It Is important that the assessments as to future outcomes of 

20 events are made independently of any other party who could be a 

counter-party to a contract. The nature of the pricing and matching, 
therefore, is totally different to conventional negotiation or bidding 
as between parties. 

The present Invention enables entitles to better manage risk, as 

25 they are able to think more explicity about possible future events 
beyond their control which they perceive will have adverse consequences 
for them. They will have the capacity to utilise existing resources to 
reduce exposure to a specific risk, and have access to a generally 
available mechanism by which they can explicity trade-off existing 

30 assets for Increased certainty about the future. They are also free to 
decide upon the degree to which they should make such trade-offs, and to 
actually effect and subsequently manage such trade-offs In a simple and 
low cost manner. 

The present Invention also provides an automated infrastructure to 
35 which parties have access without restrictions relating to nationality 
or residential requirements. This allows the parties to participate 
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directly without requiring an Intermediary. 

Therefore, in accordance with one aspect of the present invention, 
there is disclosed a data processing system to enable the formulation of 
multi-party risk management contracts, the system comprising: 

5 at least one stakeholder Input means by which ordering 

stakeholders can Input contract data representing at least one offered 
contract 1n at least one predetermined phenomenon, each said phenomenon 
having a range of future outcomes, and said contract data specifying a 
future time of maturity, entitlements due at maturity for the range of 

10 outcomes, and a consideration due to a counter-party stakeholder; 

at least one counter-party stakeholder input means by which at 
least one counter-party stakeholder can input registering data as to a 
respective view of the outcomes 1n said predetermined range of outcomes 
in the future for one or more of said predetermined phenomena; 

15 a data storage means linked with each said stakeholder input means 

and linked with each said counter-party stakeholder Input means to store 
said contract data and said registering data; and 

data processing means, linked with the data storage means, for 
pricing and matching contracts from said contract data and said 

20 registering data, said pricing Including selecting the registering data 
corresponding to the time of maturity for each predetermined phenomenon, 
and calculating a counter-consideration derived from said entitlements, 
and said matching including comparing said consideration and said 
counter-consideration to match an offered contract with at least one of 

25 said counter-party stakeholders. 

In accordance with a second aspect of the present Invention there 
Is disclosed a method to enable the formulation of multi-party risk 
management contracts, the method comprising the steps of: 

(a) Inputting Into data processing apparatus, by at least one 

30 ordering stakeholder input means thereof, contract data representing at 
least one offered contract in at least one predetermined phenomenon 
having a range of future outcomes, and said contract data specifying a 
future time of maturity, entitlement due at maturity for the range of 
outcomes, and consideration due to a counter-party stakeholder; 

35 (b) Inputting into said data processing apparatus, by at least 

one counter-party stakeholder input means thereof, counter-party 
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reglsterlng data as to a respective view of each outcome In said 
predetermined range of outcomes 1n the future for one or more of said 
predetermined phenomena; 

(c) storing, 1n a data storage means of said data processing 

5 apparatus linked with each said stakeholder means and linked with each 
said counter-party stakeholder Input means, said contract data and said 
registering data; and 

(d) pricing and matching at least one of the offered contracts, 
by data processing means of the data processing apparatus linked with 

10 said data storage means said pricing and matching comprising the steps, 
for each offered contract, of: 

(1) selecting the registering data corresponding to the 
time of maturity for a predetermined phenomenon; 

<11> calculating a counter-consideration derived from the 
15 said entitlement; 

(111) comparing the said consideration and the said 
counter-consideration; and 

<1v) matching a contract on the basis of the said comparison. 
In preferred embodiments, the ordering stakeholders and 
20 counter-party stakeholders can be considered to be contract buyers and 
contract sellers respectively. The entitlement for each outcome can be 
in the form of 'money' payoffs (both positive and negative) at maturity 
of a matched contract * or can be other types of compensation, possibly 
In the form of goods, services, promises, credits or warrants. The 
25 consideration, whether buyer specified or seller calculated, can again 
be in the nature of a premium or payments, or can relate to other 
'non-money' forms of property or obligations, typically transferable 
when a contract is matched, although possibly deferable, until, and 
potentially beyond, the time of maturity. 
30 In the period between the match of a contract and maturity the 

various buyers, sellers and other contract stakeholders can review any 
contract to which they are a party and seek to trade that contract to 
other parties by the pricing and matching procedure, or variations on 
the pricing and matching procedure. They would tend to do so If their 
35 view of the future outcome of the phenomenon, being the subject of the 
contract, had changed markedly, or as a means to minimise expected 
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losses If some unforseen adverse trend In the present day outcome of the 
phenomenon has occurred. As well as trading existing contracts, further 
contracts can be offered to 'lay off or avert risk. Stakeholder 
parties can build up a portfolio of matched contracts and offered 
5 contracts, which are continually traded to obtain the, best possible 

position at any time, and that position can be continually reviewed with 
time. 

It Is further possible for offered contracts to be based on the 
difference between phenomena, and so manage perceived risk as between 

10 the phenomena. Elemental contract phenomena can therefore be developed 
to meet the most particular needs of buyers and sellers, thus creating 
great flexibility. 

In most Instances the date of maturity will be predetermined by a 
'product sponsor 1 stakeholder, who otherwise cannot be a buyer or seller 

15 of contracts they sponsor. Even so, It Is conceivable that the date of 
maturity can be tied to a specified time from the Instant a contract 1s 
matched. This may be appropriate where the time of maturity Is 1n the 
near future, In which case offered contracts could otherwise remain 
unmatched following Initial offer even up until the time of maturity. 

20 Other stakeholders have executive roles In administration, 

guaranteeing the performance of buyers and seller, regulation, 
supervision and so on. In this way the number and types of buyers and 
sellers that can be considered In pricing and matching offered contracts 
can be control led - 

25 The Invention also encompasses apparatus and method dealing with 

the handling of contracts at maturity, and specifically the transfer of 
entitlement. 

Therefore, In accordance with a further aspect of the Invention, 
there 1s disclosed a method of exchanging obligations as between 
30 parties, each party holding a credit record and a debit record with an 
exchange Institution, the credit records and debit records for exchange 
of predetermined obligations, the method comprising the steps of: 

(a) creating a shadow credit record and debit record for each 
party to be held Independantly from the exchange Institutions by a 
35 supervisory Institution; 
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(b) obtaining from each exchange Institution a start-of-day 
balance for each shadow credit record and debit record; 

(c) for every transaction resulting In an exchange obligation, 
the supervisory institution adjusts each respective party's shadow 

5 credit record or debit record, allowing only those transactions that do 
not result 1n the value of the shadow debit record being less than the 
value of the shadow credit record at any time, each said adjustment 
taking place in chronological order; and 

(d> at the end-of-day, the supervisory Institution Instructing 

10 ones of the exchange Institutions to exchange credits or debits to the 
credit record and debit record of the respective parties In accordance 
with the adjustments of the said permitted transactions, the credits and 
debits being irrevocable, time invariant obligations placed on the 
exchange institutions. 

15 

BRIEF DESCRIPTION OF THE D RAWINGS AND APPENDICES 

A number of embodiments of the Invention will now be described 
with reference to the accompanying drawings, In which: 

Fig. 1 shows a block diagram of a generic 'system' embodying the 
20 invention; 

Fig. 2 shows a block diagram of an indicative hardware platform 
supporting the system of Fig. 1; 

Fig. 3 shows a representation of INVENTCO and its main component 

parts; 

25 F1g. 4 shows a block diagram of a subset of the components of an 

INVENTCO system's markets-depository (M-INVENTCO); 

Fig. 5 shows a block-diagram of the process components of a subset 
of one type of 'market' (termed CONTRACT APP) which can reside within 
M-INVENTCO; 

30 Fig. 6 shows a timeline applicable to Example I; 

Fig. 7 shows a timeline applicable to Example II; 
F1gs. 8 to 16 show flow diagrams of the contract pricing and 
matching methodology; 

F1g. 17 shows a timeline applicable to Example III; and 
35 Figs. 18 to 40 show flow diagrams of the first to ninth process 

components for a CONTRACT APP. 
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There are a number of 'appendices' supporting the described 
embodiments all of which form an Integral part of this specification. 
The appendices are: 

Appendix A Is a glossary of non-conventional terms; 
5 Appendix B Is a detailed description of CONTRACT APPS, and the 

stakeholders thereto; 

Appendix C is a detailed description of each of the nine processes 
of a CONTRACT APP; 

Appendix D 1s a detailed description of the nature of risk 
10 management contracts; 

Appendix E has tables and charts associated with Example I; 

Appendix F has tables and charts associated with Example II; 

Appendix G has tables and charts associated with Example III; and 

Appendix H 1s a listing of the main variables and data files used 
15 by process 2 of a CONTRACT APP. 

DETAILED DESCRIPTION OF A BEST MODE FO^ CARRYING OUT THE INVENTION 

1. Introduction 

20 The description firstly discusses the relation of the various 

users (stakeholders) of the 'system', followed by a consideration of a 
hardware data processing platform and peripheral Input/output devices by 
which stakeholders Interact with each other and the system. 
This Is followed by a discussion of the scope of the 

25 'applications' that can be supported by the system 1n relation to the 
various stakeholders, and the Interrelation of component parts thereof. 

Details as to software methodologies for Implementation of the 
applications supported by the system are also described, Including a 
number of worked examples relating to the formulation and trading of 

30 risk management contracts. 

In the course of the detailed description reference 1s made to a 
number of non-conventional expressions and terminologies. For 
convenience, an explanation of these 1s listed In Appendix A. 

35 2. 'Systems' Configurations 

Fig. 1 shows a block diagram of a generic 'system' embodying the 
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Invention. The various stakeholders or parties to the system 10 each 
have access to a centralised processing unit 20. The processing units 
20 can be constituted by one or more data processing apparatus, with 
each one thereof providing access for any one or more of the various 

5 stakeholders to applications software supported by the system 10, as all 
the processing units would be Interconnected. Access to the one or more 
data processing apparatus Is controlled by a generic form of 
communications co-ordination and security processing unit 25. 
Fig. 1 also indicates that there are a number of types of 

10 stakeholder, and a number of Individual stakeholders within each 
stakeholder type. The basic types of stakeholder are described as: 
applications promoters 11, product sponsors 12, product ordering parties 
(buyers) 13, potential product counter-parties (sellers) 14, 
counter-party guarantors 15, regulators, 16, consideration/entitlement 

15 transfer ('accounting 1 ) entities 17, and miscellaneous parties 18. The 
detailed roles of each of these stakeholders will be subsequently 
described 1n greater detail at a later time. The number of types of 
stakeholder represented 1n Fig. 1 is typically the largest that will be 
supported by the system 10. 

20 An embodiment of a computer system for the system 10 is shown in 

Fig. 2. The core of the system hardware Is a collection of data 
processing units. In the emb6d1ment described, the processing unit 20 
comprises three Inter-linked data processors 93,97,104, such as the Sun 
670 MP manufactured by Sun Microsystems, Inc. of the USA. Each 

25 processing unit 93,97,104 runs operational system software, such as Sun 
Microsystems OS 4.1.2, as well as applications software. The 
applications software Is, in part, written around the flow diagrams 
subsequently described In Figs. 8 to 16, and Figs. 18 to 40, and 
accesses, or otherwise creates, the data files as summarised In Appendix 

30 H. The processor configuration shown in Fig. 1 represents a large 

system designed to handle the transactions of thousands of stakeholders, 
the input and output data generated by those stakeholders » and risk 
management contract pricing, matching and subsequent processing 
functions. 

35 Each processing unit 93,97,104 1s operably connected with 1t one, 

or more mass data storage units 95,100,110 to store all data received 
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from stakeholders, and other data relating to all other software 
operations generating or retrieving stored Information. Suitable mass 
storage units are, for example, such as those commercially available 
from Sun Microsystems. 

5 A number of communications controllers 80,84,87, forming the 

communications co-ordination and security processing unit 25, are 
coupled with the processing unit 20. These controllers effect 
communications between the processing units 93,97,104 and the various 
external hardware devices used by the stakeholders to communicate data 

10 or Instructions to or from the processing units. The communications 
controllers are such as the Encore ANNEX II, the IBM AS/400 server or 
the CISCO Systems AGS +. 

A large range of communications hardware products are supported, 
and collectively are referred to as the stakeholder input/output devices 

15 70. One amongst many of the communication devices 70 are personal 
computers 51 and associated printers 52, which have communications 
connection with the communications controller 80 by means of a modem 
50. There can also be an external host device 53, such as a mini or 
mainframe computer, again linked with the communications controller 80 

20 by means of a modem 54. In other forms, communications can be 
established simply by means of a tone dialing telephone 56, which 
provides for the Input of instructions or data by use of the tone 
dialing facility Itself* In the alternative, a voice connection via an 
operator 75 can be effected by a conventional telephone 58. Both these 

25 external devices are shown connected with the communications controller 
84. A further possibility Is to have data transfer by means of a 
facsimile machine 65, In this case shown linked to the communications 
controller 87. 

In all cases, users of the Input devices are likely to be required 
30 to make use of system access password generation and encryption devices 
such as the Racal RG 500 Watchword Generator 66,67,68,69, (for personal 
use) and the Racal RG 1000, which Is incorporated in a mainframe 
computer 53. The corresponding decoding units for these devices are 
incorporated 1n the communications controllers 80,84,87. 
35 The generic processing unit 20 also Includes a large number of 

'portable' Information recordal devices, such as printers, disc drives, 
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and the like, which allow various forms of Information to be printed or 
otherwise written to storage media to be transferable* This 1s 
particularly appropriate where confirmatory documentation of matched 
risk contracts Is required to be produced, either for safekeeping as a 

5 hard copy record, else to be forwarded to any one or more of the 
stakeholders that are a party to each individual matched contract. 

The generic system 10 shown in F1g, 1 encompasses many varied 
configurations, relating not only to the number and types of 
stakeholders, but also the 'architectures' realisable by the system 

10 hardware and software In combination. In that sense the arrangement 
shown In Fig. 2 Is to be considered only as broadly indicative of one 
type of hardware configuration that may be required to put the Invention 
Into effect. 

The 'virtual' level of the system 10 1s termed INVENTCO. INVENTCO 

15 1s a collection of one or more potentially Interrelated systems, as 
shown In Fig. 3. Each INVENTCO system (INVENTCO SYSTEM #1... INVENTCO 
SYSTEM #N> enables the formulation and trading of a wide range of 
contractual obligations, Including risk management contracts. The 
hardware configuration shown in Fig. 2, is to be understood both as a 

20 realisation for a single INVENTCO system, and equally can represent a 
number of INVENTCO SYSTEMS, where the processing unit 20 Is common to 
all and supports a number of communications co-ordination and security 
units 25, others of which are not shown, together with associated 
external communications devices 70, also not shown. 

25 While INVENTCO allows the formulation and trading of risk 

management contracts, 1t is also responsible for processing of such 
contracts through to, and including, their maturity, and 1n some 
respects, subsequent to maturity. 

Nhere there are a number of INVENTCO systems, those systems may be 

30 inter-dependent or stand-alone in nature. If inter-dependent, INVENTCO 
(10) Is responsible for transactions between those systems. 

INVENTCO and all of its component parts can be legally or 
geographically domiciled 1n separate countries or states. The 
supra-national nature of INVENTCO enables the stakeholders to avail 

35 themselves of the risk management mechanisms independently of legal 
domicile or other such restrictions that are often a feature of some 



WO 94/28496 



PCT7AU93/00250 



-14- 

conventional risk management mechanisms, subject to meeting certain 
criteria regarding credit worthiness and such. Indeed,, the legal 
domicile, location, ownership and participating stakeholders of 
INVENTCO, or any of the sub-systems, can be continually changing. 

5 Fig, 3 further shows that each INVENTCO SYSTEM comprises an 

Infrastructure component, termed I-INVENTCO, and a markets depository 
component M-INVENTCO. I-INVENTCO Is concerned with coordination of 
communl cations and other security considerations, that part termed 
AXSCO, and also provides a network and general management system, termed 

10 VIRPRO. M-INVENTCO 1s a depository of authorised product-market 

(applications) software residing within INVENTCO under the authorisation 
of VIRPRO, and as distributed using I-INVENTCO. 

One or more local or wide area telecommunication networks may link 
VIRPRO and M-INVENTCO to AXSCO, and thus to each other. In this way 

15 both VIRPRO and M-INVENTCO effectively reside around AXSCO. 

AXSCO therefore comprises multiple, uniquely addressed 
communications controllers linked together In a number of possible 
ways. In one embodiment, AXSCO Is represented by the communications 
co-ordination and security processing unit 25 shown In Fig. 2. The 

20 component hardware, such as the three controllers 80,84,87 shown In F1g. 
2, typically are responsible for three types of operational 
applications. The first is in respect of time stamping data received 
from other parts of INVENTCO and data similarly transmitted to entitles 
external of INVENTCO. The second is in respect of protecting the 

25 identity and/or location of entities within INVENTCO from one another, 
and from entitles external to INVENTCO. The third is responsible for 
overall management of the routing of data received and to be transmitted 
within INVENTCO and to external entities thereto. 

Referring now to Fig. 4, within M-INVENTCO reside different 

30 collections of system sponsored phenomena or 'markets', one collection 
of which is termed CONTRACT APPS. Each CONTRACT APP within the CONTRACT 
APPS 'markets' collection Is essentially related to a specific type of 
risk management phenomenon. The purpose of individual CONTRACT APPS is 
two-fold. First, to effect the trading/exchange/transfer of risk 

35 management contracts (and derivatives of these transactions) between 
participating product ordering parties and counter-parties on terms 
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acceptable to the parties Involved, as well as to others within INVENTCO 
registered as having a legitimate Interest 1n the nature, size and 
composition of these trades/exchanges/transfers. And second, to 
appropriately manage all matched/confirmed contracts through to their 

5 time of maturity. 

Individual CONTRACT APPS are responsible for performing the 
above-described tasks according to the specific rules they embody, 
defined by their applicable stakeholders. 

The role played by the various stakeholders to CONTRACT APPS, 

10 remembering that In many cases It would not be necessary to have the 
Involvement of all the possible types of stakeholder, briefly stated 1s 
as follows: 

(a) An application promoter Is an entity having overall 
responsibility for the functioning of a CONTRACT APP, having being 

15 granted that responsibility by VIRPRO. 

(b) A product sponsor 1s an entity which promotes and administers 
the rules of trading, and subsequent management of defined 
"products" selected for inclusion 1n a CONTRACT APP by its 
application promoter. 

20 (c) An ordering party (buyer) Is an entity seeking to acquire a 

CONTRACT APP product from a potential counter-party (seller), 
(d) A counter-party (seller) Is an entity potentially prepared to 
satisfy the CONTRACT APP product needs of an ordering party 
(buyer). 

25 (e) A guarantor 1s an entity guaranteeing a seller's ability to 

settle or meet obligations as a result of a CONTRACT APP effected 
match. 

(f) Regulators are entities overseeing the on-going performance 
of all other stakeholders involved in a CONTRACT APP, and 

30 especially guarantors. 

(g) Consideration/entitlement transfer ('accounting') entities 
are those parties with which ail other CONTRACT APP stakeholders 
maintain 'accounts' to transfer required 
considerations/entitlements to or from each other. 

35 (h) Other miscellaneous parties are those having some other 

defined stake 1n the functioning of a CONTRACT APP. 
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In any Implementation of the system, multiple numbers of each form 
of stakeholder are accommodated. A detailed consideration. of the nature 
of CONTRACT APPS and the types of stakeholders to a CONTRACT APP Is 
given In Appendix B. 
5 As shown 1n Fig. 5, any one CONTRACT APP consists of a cluster of 

nine (and potentially more, or fewer) specific processes, these Include: 

(a) a process handling file administration and updating tasks 
supporting all other processes (termed Process 1); 

(b) a process handling the receipt and processing of "primary" 
10 risk aversion contract transactions (termed Process 2); 

(c) a process handling the receipt and processing of "secondary" 
risk aversion contract transactions (termed Process 3); 

(d) a process handling the receipt and processing of 
"derivative-primary" risk aversion contract transactions (termed 

15 Process 4); 

(e) a process handling the receipt and processing of 
"derivative-secondary" risk aversion contract transactions (termed 
Process 5); 

(f) a process handling the "back office" management of all four 
20 types of risk aversion contract transactions, and transactions 

handled by Processes 7 to 9 (termed Process 6); 

(g) a process handling non-CONTRACT APP-transact1on related 
consideration, entitlement, and other "payment" obligation 
transfers between stakeholders (termed Process 7); 

25 (h) a process handling CONTRACT APP (and authorised other 

INVENTCO) stakeholder access to specialist systems to assist the 
stakeholder concerned to decide how best to Interface with a 
defined element of INVENTCO (termed Process 8); and 
(1) a process handling CONTRACT APP (and authorised other 

30 INVENTCO) stakeholder access to a range of INVENTCO-facllltated 

"value added services" (termed Process 9). 

A detailed discussion of the nine CONTRACT APP processes Is given 
1n Appendix C. 

All these processes collectively access multiple data files and 
35 multiple records within these files. A description of the variables and 
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data files used by Process 2, a key component process of a CONTRACT APP, 
is provided 1n Appendix H. 

The foregoing description identifies the essential inter-reaction 
between the hardware platform and the applications computer software run 
5 thereon. 

A first example of the life-cycle of a risk management contract 
will now be described. A further detailed discussion of the nature of 
risk management contracts is given In Appendix D. 
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3. Life Cvcle o f Risk Management Contract: Example I 

The first example of a risk management contract describes a 
contract to manage risk associated with faults 1n microprocessors. In 

5 summary, the example shows how the system could enable one party, such 
as a supplier of military standard equipment seeking to avoid the 
adverse consequences of faulty microprocessors (specifically, 64-bit 
microprocessors) used In that equipment to make a contract with another 
party, such as a manufacturer of these microprocessors, who Is seeking 

10 to exploit an opportunity based on their view of the future Incidence of 
faults 1n the microprocessors they produce. 

The specific offering 1s one which provides a contract ordering 
party with a specified contingent entitlement to "exclusive production 
warrants" (XPWs). That 1s, warrants providing the holder with priority 

15 access to a specified quantity of replacement and additional 
microprocessors sourced, Immediately, from a defined, different, 
guaranteed high-quality, production line available to the supplier In 
consideration of payment of a money amount. The XPW entitlement Is 
contingent on the value, at contract maturity date, of a percentage 

20 Index of the proportion of 64-bit microprocessors shipped by the 

manufacturer, during a specified prior period, which are subsequently 
determined to be faulty to a defined degree; The defined degree, in 
this case, Is the microprocessor being fault-free, as determined by 
successful completion of self-tests. 

25 In this example, the relevant key stakeholders are: an application 

promoter (Demdata Inc); various product sponsors (the relevant one for 
the example being Demdata Inc itself); various primary product ordering 
parties (the relevant one for the example being Denisons); a single 
potential counterparty (Demdata Inc again); and an application regulator 

30 (the Department of Defence). 

The timeline depicting the steps in the contract from the first 
step, Application Specification, to the final step, Contract Settlement, 
is shown in Fig. 6. Appendix E contains eight detailed explanatory 
charts supporting Fig. 6. This Appendix should be read together with 

35 the following description. 

Looking at the first step in the timeline (Application 
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Spedfl cation) in conjunction with chart E2, it can be seen that Demdata 
Inc established a Contract APP (Application ID 100) on 92.02.10*17.00.00 
(that 1s, in Inverse order, 5pm on February 10, 1992) to deal with 
defect liability management. Application ID 100 supports a range of 

5 products (Applicable Product ID'S 1200-1250), 

Looking at the second step in the timeline (Product Specification) 
in conjunction with chart E3, it can be seen that Demdata was also 
Product Sponsor of Product 1210 at the same time (92.02.10.17.00*00). 
This Product relates to the market termed: Factory Output Quality 

10 Indices, and to the sub-market termed 64-bit Microprocessor Fault 
Tolerance Index. The maturity date for Product 1210 1s 
95.02.10.17.00.00.00. The consideration for a specific contract 
involving Product 1210 is In the form of money (commercial bank deposits 
denominated 1n Australian dollars). The entitlement Is 1n the form of 

15 Exclusive Product Warrants (XPWs); these entitle the contract ordering 
party to priority access over the forward production capacity of a 
defined, guaranteed-Mgh-quality, 64-bit microprocessor production 
line. Product 1210 specifies a range of 0% to 1001 in 2% increments 1n 
respect of the sub-market outcomes. 

20 Looking at the third step in the timeline (Potential Counterparty 

Product Pricing Specifications), it can be found that Demdata Is acting 
as the sole potential counterparty for forthcoming primary product 
orders dealing with Product 1210. At this point In the timeline 
(93.07.01.14.00.00.00), 17 months after the specification of Product 

25 1210, Demdata has currently-specified parameters for pricing potentially 
forthcoming orders for the product. 

Looking at the fourth step 1n the timeline (Primary Order 
Specification) In conjunction with chart E4, it can be seen that an 
Ordering Party, Denisons, Is seeking a contract (from the offering 

30 party, Demdata) in Product 1210 at that time (93.07.01.14.25.30.00). 
chart E4 shows the specific 'pay-off parameters that Denisons has 
defined for the contract It Is seeking at this time, Including a maximum 
acceptable contract consideration (premium) amount of 32,000 
(denominated in commercial bank, Australian dollars). 

35 Looking at the fifth step 1n the timeline (Order Specification 

Pricing) in conjunction with chart E5, 1t can be seen that Demdata 
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(uslng the specified pricing parameters set at 93.07.01,14.00.00,00) 
prices the Denlson order at 93.07.01.14.26.40.00. Demdata;s pricing 
parameters Indicate that their appropriate Defined Circumstances ID for 
Denlsons Is 14. As 1s shown, this ID In turn Implies a Commission Rate 

5 of 1.10%, a Discount Rate of 9.90%, a particular set of Component 
product prices and a particular set of Assessed Probabilities of 
Occurrence over the range of feasible product values (outcomes). 

The Contract Bid Price 1s calculated automatically by the 
application software In the following manner: The ordering 

10 party-specified desired contingent entitlement amounts, i.e. the 
"registered data", (covering the feasible product definition value 
range) are multiplied by the potential counterparty-specified component 
product prices (which will rarely add to "1" because each counterparty 
1s endeavouring to 'game 1 potential ordering parties in different ways) 

15 to yield the corresponding number of implied contingent entitlement 
amounts. When added together, these figures sum to (34.110), where the 
brackets signify a negative value. This figure represents an expected 
future counterparty-entitlement payout amount (as at the designated 
contract maturity date of 95.02.10.17.00.00). The present day value of 

20 this figure, calculated using the specified discount rate of 9.901 per 
annum, 1s 29,220. To this amount Is added the potential counterparty's 
desired flat commission amount of 1.101, yielding a contract Bid Price 
(In the consideration/entitlement denomination of the product, 
commercial bank-denominated Australian dollars) of 29,540. No exchange 

25 rates are applicable In this case, because the ordering party, Denlsons, 
is not seeking to deal In a consideration or entitlement denomination 
different to the denominations formally specified for the product. 
Demdata's parameters calculate that a consideration bid price of 29,540 
will yield them a base margin on the contract of 3,180 (again 

30 denominated in commercial bank, Australian dollars). 

This margin amount is calculated in the following manner: The 
ordering party-specified desired contingent entitlement amounts 
(covering the feasible product definition value range) are multiplied by 
the potential counterparty-specified assessed probabilities of 

35 occurrence to yield a corresponding number of net contingent entitlement 
valuation amounts. When added together, these sum to (30.770). 
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This amount represents an expected future counterparty-entitlement 
loss-on the contract (as at the designated contract maturity date of 
95*02.10.17.00.00). The present value of this amount, calculated using 
the specified discount rate of 9.90X per annum, 1s 26,360. Thus, 

5 (Ignoring for this example the margin Demdata may gain from using, 1n 
some manner, the consideration amount of 29,540 through to the time the 
contract expires, and various transaction fees) the margin Demdata can 
expect from entering Into this contract with Denlsons Is their 
calculated present-value indifference price of 29,540 less their 

10 calculated present-value expected loss on the contract of 26,360 (or 
3,180). 

The amounts In the last two rows of the table contained on E5 are 
used for checking that this contract, 1f entered Into by Demdata, will 
not result 1n them violating any self Imposed portfolio valuation or 

15 composition limits. This notion Is explained 1n detail 1n Example III. 

Looking at the sixth step 1n the timeline (Order Matching), 1t can 
be found that Demdata 1 s contract bid price of 29,540 Is below Denison's 
specified maximum consideration price of 32,000, leading to a matching 
of the order at 93.07.01.14.29.10.00. 

20 The seventh step in the timeline (Order/Contract Confirmation) can 

be seen to take place twelve minutes later at 93.07.01.14.38.50.00, 
after the system has determined that Denlsons Is able to (and then does) 
Immediately pay the required consideration funds amount of 29,540 to 
Demdata. 

25 Looking at the eighth step In the timeline (Contract Valuation) In 

conjunction with chart E6, it can be seen that a contract valuation 
report for Denlsons was published not much longer than one hour after 
confirmation of the contract, that is, at 93.07.01.16.00.00.00. As can 
be seen, the market estimate of the future product value of the 64BMFT 

30 Index at this moment Is 38 (with a standard deviation of 4), which 
implies that this contract has an expected future value of 29,330 XPWs 
(with a standard deviation of 6,213). 

On chart E7 1t can be seen the equivalent report for Demdata Inc 
of their expected future entitlement payout is identical to Denlsons' 

35 expected future entitlement receipt (ignoring future fee payments which 
may be netted against these payments/receipts). The above-described 
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market estimate of the future product value 1s determined by the system 
applying a defined composite of contract-counterparty assessed 
probabilities of occurrence figures drawn from the collection of all 
like contracts recently matched/confirmed by the system. 

5 The ninth step In the timeline (Contract Valuation) refers to a 

contract valuation report published for Denlsons sixteen months later, 
at 94.11 •15-10.00.00.00 (see chart E8>. As can be seen, the market 
estimate of the future product value of the 64BMFT Index at this moment 
1s 58 (with a standard deviation of 5), which implies that this contract 

10 now has an expected future value of 42 J 60 XPWs (with a standard 

deviation of 6,209). This is an Increase 1n expected future value of 
12,830 XPWs for Denlsons since the former valuation date/time. 

The tenth step 1n the timeline. Contract Maturity, refers to the 
actual determination of the product value at time of maturity, 

15 95.02.10.17.00.00.00. As can be seen on chart E9, this product value of 
the 64BMFT Index was specified by Demdata (as Product Sponsor) to be 74, 
implying a contract value of 100,660 XPWs to Denlsons and a 
corresponding obligation on Demdata. The amount of 74 represents the 
percentage of 64-bit microprocessors shipped by Demdata, during a 

20 specified period some time before the designated contract maturity date, 
which are subsequently determined (possibly by the application 
regulator, The Department of Defence) to be faulty. 

The eleventh step 1n the timeline Involves the formal assignment 
of 100,660 XPWs by Demdata to Denlsons (Ignoring possible fee payments 

25 by one or both parties). 
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4. Life Cvcle of Risk Management Contract: Example II 

The second example describes a risk management contract associated 
with the utilisation of telecommunications carrying capacity. In 

5 summary, the example shows how the system could enable one party (a 

telecommunications carrier) seeking to avoid the adverse consequences of 
under and over-committing their call carrying capacity between specified 
points (say, between the two cities, New York and Boston) to make a 
contract with another party (say, another telecommunications carrier 

10 with call carrying capacity between the same two cities) similarly 
prepared to hedge against the consequences of this occurring. 

The specific offering 1s one which provides a contract ordering 
party with a specified contingent entitlement to transmission time units 
between the hours 1200-1800 dally on the NY-Boston link within a defined 

15 future period (termed, Prime ITU's) upon assignment by the ordering 
party - to the counterparty - of a calculated consideration amount of 
Prime TTUs on the ordering party's own NY-Boston line within another 
defined future period (these defined TTUs may or may not be convertible 
to TTUs on other city links). The TTU entitlement is contingent on the 

20 value, at contract maturity date, of the log of the difference between 
the ordering party's utilisation of the counterparty's network and the 
counterparty's utilisation of the ordering party's network, during a 
specified prior period ending on the contract maturity date. 

In this example, the relevant key stakeholders are: an application 

25 promoter (Newcom Inc); various product sponsors (the relevant one for 
the example being Newcom Inc Itself); various primary product ordering 
parties (the relevant one for the example being Basstel Co.); two 
potential counterparties (Tasnet and Aarcom); and an application 
regulator (ITT). 

30 The timeline depicting the steps In the contract from the first 

step, Application Specification, to the final step, Contract Settlement, 
is shown in Fig. 7. Appendix F contains nine detailed explanatory 
charts supporting Fig. 7. This Appendix should be read together with 
the following description. 

35 Looking at the first step in the timeline (Application 

Specification) in conjunction with chart F2 t it can be seen that Newcom 
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Inc established a Contract APP (Application ID 001) on 
93.11.01.17.00.00 (that 1s, 5pm on November 1,1993) to deal with 
hardware capacity management. Application ID 001 supports a range of 
products (Applicable Product ID's 2001-2020). 

5 Looking at the second step 1n the timeline (Product Specification) 

in conjunction with chart F3, It can be seen that Newcom Inc was also 
Product Sponsor of Product 2001 at the same time (93.11.01.17.00.00). 
This Product relates to the market termed Telecommunications Carrying 
Capacity and to the sub-market termed Prime TTUs. The maturity date for 

10 Product 2001 Is 96.11.01.17.00.00.00. The consideration for a specific 
contract Involving Product 2001 Is In the form of "Ordering Party 
TTUs". The entitlement Is In the form of "Counterparty TTUs"; these 
entitle the contract ordering party to "transmission time units between 
the hours 1200-1800 daily on the NY-Boston link (within a defined future 

15 period)". The feasible values of PRIME TTUs are normalised 1n the range 
of -1.0 to +1.0, respectively signifying the proportionate utilisation 
of respective networks as between the parties to a contract. 

Looking at the third step in the timeline (Potential Counterparty 
Product Pricing Specifications), one can find two other carriers, 

20 Tasnet and Aarcom, acting as potential counterparties for forthcoming 
primary product orders dealing with Product 2001. At this point in the 
timeline (94.06.01.14.00.00.00), 7 months after the specification of 
Product 2001, both Tasnet and Aarcom have currently-specified parameters 
for pricing potentially forthcoming orders for the product. 

25 Looking at the fourth step in the timeline (Primary Order 

Specification) in conjunction with chart F4 f It can be seen that an 
Ordering Party, Basstel Co., is seeking a contract, from an offering 
party, in Product 2001 at that time (94.06.01.14.25.30.00). Chart F4 
shows the specific parameters (entitlements) that Basstel Co. has 

30 defined for the contract it Is seeking at this time, including a maximum 
acceptable contract consideration amount of 58,000 (denominated in Its 
own TTUs). 

Looking at the fifth step in the timeline (Order Specification 
Pricing) in conjunction with chart F5, it can be seen that Tasnet (using 
35 the specified pricing parameters set at 94.06.01.14.00.00.00) prices the 
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Basstel Co. order at 94.06.01.14.26.40.00. Tasnet's pricing parameters 
Indicate that their appropriate Defined Circumstances ID for Basstel Co. 
1s 8. As is shown, this. ID In turn Implies a Commission Rate of 1.00%, 
a Discount Rate of 9.90% per annum, a particular set of Component 

5 product prices and a particular set of Assessed Probabilities of 

Occurrence. In a similar process to that described for Example I, this 
results In a Contract Bid Price of 55,180 (denominated in Basstel Co. 
TTUs), which Tasnet's parameters calculate will yield them a base margin 
on the contract of 10,760 (again denominated 1n Basstel Co. TTUs). 

10 Still looking at the fifth step in the timeline, in conjunction 

with chart F6, It can be seen that Aarcom (again using the specified 
pricing parameters set at 94.06.01.14.00.00.00) also prices the Basstel 
Co. order at 94.06.01.14.26.40.00. Aarcom's pricing parameters Indicate 
that their appropriate Defined Circumstances ID for Basstel Co. Is 9. 

15 As 1s shown, this ID In turn Implies a Commission Rate of 0.90%, a 

Discount Rate of 8.50% per annum, a particular set of Component product 
prices and a particular set of Assessed Probabilities of Occurrence. 
This results in a Contract Bid Price of 55,390 (denominated In Basstel 
Co. TTUs), which Aarcom's parameters calculate will yield them a base 

20 margin on the contract of 9,430 (again denominated In Basstel Co. TTUs). 

Looking at the sixth step In the timeline (Order Matching) It can 
be found that Tasnet's price bid of 55,180 Is below Aarcom's bid of 
55,390 and, 1n turn, that the 55,180 amount is below Basstel Co.'s 
specified maximum consideration price of 58,000. This leads to a formal 

25 matching of Basstel Co,'s order by Tasnet at 94.06.01.14.29.10.00. 

The seventh step In the timeline (Order/Contract Confirmation) can 
be seen to take place nearly ten seconds later at 94.06.01.14.38.50.00, 
after the system has determined that Basstel Co. Is able to (and then 
does) Immediately assign the required consideration amount of 55,180 

30 TTUs to Tasnet. 

Looking at the eighth step 1n the timeline (Contract Valuation) 1n 
conjunction with chart F7, one can see a contract valuation report for 
Basstel Co. published about two hours after confirmation of the 
contract, that Is, at 94.06.01.16.00.00.00. As can be seen, the market 

35 estimate of the future product value of the log of the difference 



WO 94/28496 



PCT/AU93/00250 



-26- 

between Basstel Co.'s utilization of Tasnet's network and Tasnet's 
utilization of Basstel Co.'s network (during a specified prior period 
ending on the contract maturity date) at this moment Is (0.150) (with a 
standard deviation of 0.023), which implies that this contract has an 

5 expected future value of 54,236 Tasnet TTUs (with a standard deviation 
of 9,207). On chart F8 one can see in the equivalent report for Tasnet 
that their required expected future entitlement payout is Identical to 
Basstel Co.'s expected future entitlement receipt (Ignoring future fee 
payments which may be netted against these payments/receipts). 

10 The ninth step in the timeline (Contract Valuation) refers to a 

contract valuation report published for Basstel Co. five months later, 
at 94.11.22.10.00.00.00 (see chart F9). As can be seen, the market 
estimate of the future product value of the log of the difference 
between Basstel Co.'s utilization of Tasnet's network and Tasnet's 

15 utilization of Basstel Co.'s network (during a specified prior period 
ending on the contract maturity date) at this moment is (0.400) (with a 
standard deviation of 0.010), which Implies that this contract now has 
an expected future value of 350,181 Tasnet TTUs (with a standard 
deviation of 74,200). This Is an Increase 1n expected future value of 

20 295,945 TTUs for Basstel Co. since the former valuation date/time. 

The tenth step 1n the timeline (Contract Maturity) refers to the 
actual determination of the product value at time of maturity, . 
96.11.01.17.00.00.00. As can be seen on chart F10, this product value 
of TTU's was specified by Newcom Inc (as Product Sponsor) to be (0.400), 

25 unchanged from the prior valuation date/time, implying a contract value 
of 368,340 Tasnet TTUs to Basstel Co. and a corresponding obligation on 
Tasnet. The amount Is higher than the prior valuation figure due to the 
actual determination figure being naturally without a standard deviation 
element. 

30 The eleventh step in the timeline Involves the formal assignment 

of the 368,340 TTUs by Tasnet to Basstel Co. (ignoring possible fee 
payments by one or both parties). 
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5. PRIMARY PROPUCT PRP5R PROCESSING 

Before describing the third, and most detailed, example, 
consideration will be given to the 'core 1 product (contact) ordering, 

5 pricing and matching processes. Note that expressions such as (PORD 
NEW) represent file names. 

The flow charts In FIGS 8 to 16 depict the processing flow of the 
matching system for primary product orders submitted by ordering party 
stakeholders to a CONTRACT APP, where this APP Is based upon: an EV-CE 

10 counterparty pricing regime (assuming paid consideration amounts do not 
yield an Income stream 1n their own right); a sequential order matching 
process; consideration/entitlement value dates which are immediately 
after a product sponsor-designated date/time; and matching rules which 
do three things: First, identify, for each ordering party's order, a 

15 counterparty offering the lowest price bid for an order, subject to this 
price being at or below the specified maximum price the ordering party 
has Indicated it is prepared to pay. Second, accommodate portfolio 
expected loss constraints on an 'equivalent maturity date products 1 , 
'same-month maturity products', and 'all -products' basis. And third, 

20 apply the above-described matching rules on a pre-tax basis, with 
partial matching of product orders, and without conditional order 
matching rules. 

As shown in Fig. 8, starting at block 610, and proceeding to block 
625, the system determines which set of orders to process, authorises 

25 these orders, matches them with counterparties where possible, and then 
confirms them. As shown in blocks 1010 to 1070 In Fig. 9, the system 
holds newly submitted orders (PORD NEW), and all previously submitted, 
but as yet unmatched, orders which are defined as queued orders (PORD 
QUEUE). Parameters and algorithms can be Implemented to give the system 

30 the ability to determine whether new or queued orders are to be 

processed at any time. For example, a simplistic algorithm would be to 
alternate between PORD NEW and PORD QUEUE one order at a time. Another 
example would be to load queued orders only when there is a change in 
the counterparty parameters. Test 1020 checks the decision made in block 

35 1010. 

For new orders, the system moves to block 1030. Details of the 
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next recorded new order are loaded from the PORD NEW master file (block 
1040). The order data fields Include: the ordering party Identification 
(BID); the ordering party's own reference (BREF); the product 
Identification (PID) specified by the ordering party; the entitlement 

5 "payoff" function type (PAYFUNC); the parameters for the entitlement 
"pay off" function (PAYPARAM); a "deal type" identifier (DTID); the 
anonymous and manual deal Identifiers (0AN0N and OMANUAL); the order 
retention time limit (RET LIM); the maximum consideration the ordering 
party is prepared to pay (MAXCONSID); the number of the account from 

10 which the consideration Is to be "paid" (ACC CONSID); and the number of 
the account to which any entitlement "pay off" amount 1s to be paid (ACC 
ENTITL) . With this Information set, the system's next step Is to 
authorise the order. This occurs at block 1050. 

15 Order Authorisation 

Blocks 1100 to 1162 In Fig. 10 provide an expansion of block 1050. 
Starting at block 1100 the order is assigned a unique Identification, 
which 1s set in the order data field 0ID. Before verifying the order, 
additional information is required by the system. At block 1110, details 

20 of the product (order data field PID) are loaded from the master file 
PPR0DUCT (block 1120). The information Includes the product maturity 
date (PMAT); the product consideration/entitlement denomination (PC/ED); 
the product currency denomination (PCUR) and national currency 
denomination (PNCUR); and the product limits and parameters (PMIN, PMAX, 

25 and PSTEP). The test 1130 checks that the order parameters are 
consistent with the master file parameters implied by the defined 
product Identification (PID). Orders which fall this test are rejected 
at block 1140, with details of these orders being stored In the master 
file PORD REJ (block 1150). In turn, the ordering party is Informed of 

30 this event (block 1160). Processing then returns to the start of the 
flow chart (block 1010), ready to load the next order. When an order is 
authorised, processing continues at block 640. 

In the case of a queued order being loaded (block 1060), the order 
fields are set using the details stored 1n the queue file PORD QUEUE 

35 (block 1070). This data Is a combination of new order data (as described 
in block 1030) and the data loaded/set when the order was originally 
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verlfled (block 1110). Authorised order processing continues with the 
order matching process at block 640. 

Order Hatching 

5 Blocks 1200 to 1616 In Figs. 11 to 15 provide an explanation of 

block 640. Orders have retention time limits , stored 1n the order 
variable RET LIM. Test 1200 checks that the order retention time has not 
expired. If 1t has, the order 1s rejected at block 1210, with the order 
details copied to the rejected order file (P0RD REJ). The ordering party 

10 Is then informed of the rejection at block 1230, and processing returns 
to the main loop via connector "A". If the order 1s still valid, the 
order matching process proceeds. The aim now 1s to find a suitable 
counterparty (or counterparties) who "prices" the ordering party's 
"entitlement function" within the limits set by the ordering party- 

15 Starting at block 1240, the matching process described is one which 
seeks to Identify, for each ordering party's order, a counterparty 
offering the lowest "price bid" for an order subject to this price being 
at or below the specified maximum "price" the ordering party has 
Indicated It Is prepared to pay. 

20 Blocks 1300 to 1370 in Fig. 12 provide an explanation of block 

1240. The first step is to narrow down a group of counterparties 
prepared to at least deal with the ordering party. This is described as 
obtaining the available counterparty short 11st. First the counterparty 
short list 1s wiped (block 1300). Next, the order data fields BID 

25 (ordering part Identification) and PID (product identification) are used 
to search the PDEAL LIST master file (block 1320) for all counterparties 
prepared to consider dealing with the ordering party In the specified 
product. Any stakeholders who have set a MANUAL or ANON flag are also 
loaded. For each counterparty selected, SID Is set to the corresponding 

30 identification. Test 1330 commences a loop which allows every 
counterparty available to be dealt with in turn. For any currently 
selected counterparty (with Identification set In SID), the data flow 
proceeds to test 1365. Where the order data field 0AN0N has been set by 
the ordering party and some stakeholder requires manual confirmation 

35 (MANUAL (SID)), the current potential counterparty 1s not Included in 
the short list. Likewise if the ordering party set 0MANUAL and some 
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other stakeholder required anonymity (ANON (SID))- In both cases, data 
flow returns to test 1330. Otherwise, flow continues at block 1335. At 
this point, the system determines the applicable "defined circumstances" 
for the order. It uses the order data fields currently loaded and 

5 parameters set 1n the PSEL DC masterflle (block 1336) to determine this. 
At block 1340, pricing parameters including consideration/entitlement 
exchange rates (If applicable), commission rates, and discount rates are 
selected from the PSEL PRICE master file (block 1350). Using the 
"defined circumstances" identification (set in DCID) all potential 

10 counterparties can have different sets of pricing parameters specified 
based on any of the order data fields of each order. Test 1360 checks 
that all the necessary parameters have been found. It is possible that 
the counterparty, though prepared to deal with the ordering party, does 
not have a complete set of pricing parameters for the current order 

15 specifications. Such a counterparty is not included in the counterparty 
short list, and processing returns to test 1330. At block 1370, the 
counterparty is added to the counterparty short list by including the 
pricing details in the variables: PRICEFUNC(SID), CR(SID), DR(SID), 
C-C/EDXCHANG(SID), C-CXCHANG(SID) , C-NCXCHANG(SID) , E-CZEDEXCHANG(SID) , 

20 E-CXCHANG(SID), E-NCXCHANG(SID), MANUAL(SID) t and ANON(SID). Processing 
then returns to test 1330 where the next selected potential counterparty 
1s dealt with. When all selected potential counterparties have been 
processed, program flow returns to block 1250. At this point a potential 
counterparty short list has been obtained. 

25 Blocks 1400 to 1550 in F1gs. 13 and 14 depict block 1250 1n more 

detail, where every potential counterparty has Its price offer 
calculated, based on their Individual pricing parameters, for the 
currently loaded order. At block 1400 a loop commences allowing each 
potential counterparty in the potential counterparty shortlist to be 

30 dealt with in turn. SID is set to the identification of the counterparty 
currently selected. Test 1410 checks whether any counterparties are left 
for processing. At block 1420, the potential counterparty's price bid is 
calculated. Blocks 1490 to 1550 describe this calculation in more 
detail. At block 1490 the variable, INDEX, 1s assigned the starting 

35 value of the product value range (PMIN). Also, "price" Is initialised to 
zero. Test 1500 commences a loop, where every Index point in the product 
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range 1s traversed. Block 1520 calculates the pricing value returned by 
the potential counterparty's pricing function, PRICEFUNC, as stored In 
(PRICEFUNC(SID)), at the current Index point, and stores the value 1n 
PI. Block 1530 determines the pay-off amount required by the ordering 

5 party at the current Index point and stores this value In P2. At block 
1540, the total price at the current Index point 1s calculated by 
multiplying PI by P2. This value Is added to the running total stored 1n 
PRICE(SID). At block 1550, the Index counter (INDEX) 1s Incremented by 
the product step size (PSTEP), and flow returns to the test 1500. When 

10 the end of the product range has been reached (PMAX), flow proceeds to 
block 1510, where the calculated price bid 1s modified by the following 
calculation: 

PRICE(SID) = PRICE(SID) * E-C/EDXCHANG(SID) * E-CXCHANG(SID) * 
E-NCXCHANG(SID). 

15 Returning to block 1430, the price bid stored In PRICE(SID) will 

be 1n the applicable product's consideration/entitlement denomination, 
currency denomination, and national currency denomination* The following 
steps (block 1430-1470) determine and apply the applicable discount rate 
to the calculated price bid (currently 1n future value terms) to yield a 

20 price bid In present value terms. This Is done as follows: At block 1430 
the number of days to product maturity 1s determined. Block 1440 
Initialises the loop counter and discount rate divisor. For each day (or 
appropriate part thereof) between the current date/ time and the product 
maturity date/time, the divisor Is changed according to the formula 

25 (block 1460): 

DIV « DIV * (1 + ((DR(SID) / 100) / 365)) 

At block 1470, the price bid Is adjusted according to the formula: 
PRICE(SID) o PRICE(SID) / DIV 

Once the price bid In present value terms 1s known, the potential 
30 counterparty's defined commission Is added to the price (block 1480). 
Given that CR(SID) Is a percentage commission rate, the formula 1s: 
PRICE(SID) = PRICE(SID) + ((CR(SID) 7 100) * PRICE (SID)> 
When test 1410 confirms that every potential counterparty has been 
priced, program flow continues at 1255. 
35 The test at 1255 checks whether the order was a "quote only" 

order. If so, flow continues at block 1256 where one or more of the 
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counterparty bid prices are selected. At block 1230, the ordering party 
Is Informed of the pricing Information gathered. If the order was not a 
quote order (that is, It was a real product order), an attempt is now 
made to Identify a counterparty from the potential counterparty short 
5 list matching the requirements of the current order. This 1s done at 
block 1260. Blocks 1560 to 1616 1n Fig 15 describe this process in 
detail. 

Starting at test 1560, a check Is made to ensure the potential 
counterparty shortlist is not empty. If It Is, no match Is possible and 

10 flow continues at block 1612. At this point SID Is assigned "0" to 
indicate that no counterparty was selected from the potential 
counterparty short 11st, before moving to block 1614 where the entire 
order (as no part was matched) Is queued* When the 11st is not empty, 
program flow continues at block 1570, where the lowest priced 

15 counterparty is selected from the counterparty short! 1st. This 

determination is done based upon each potential counterparty's bid price 
(PRICE(SID)), being converted to the consideration/entitlement type, 
currency, and national currency consideration "payment" denominations 
sought by the ordering party (that is, PRICE(SID) « PRICE(SID) * 

20 C-C/EDXCHANG(SID) * C-CXCHANG(SID) * C-NCXCHANG(SID)) . The counterparty 
Identification Is stored In SID, and Its price offer is stored In 
BPRICE. At block 1580, the following check Is made: 
BPRICE > MAXC0NSID 

If the selected price Is greater than the ordering party's 
25 specified maximum consideration payment (MAXCONSID) limit, a match with 
the current potential counterparty is not deemed possible. This must 
also be true for any of the remaining counterparties in the counterparty 
short list. This part of the matching process returns without any 
potential counterparty in the short list having been selected for a 
30 match (block 1612). Otherwise, the current price is acceptable, and the 
process proceeds to attempt a match with the current selected 
counterparty. 

The next step (block 1590), requires all the applicable contract, 
product, and portfolio absolute loss, expected loss, expected value 
35 limits, and maximum composition limits to be read from the PSEL LIMIT 
master file (block 1600) and stored in ALU (SID), ALL2(SID), ELLKSID), 
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ELL2(SID), ELL3CSID), ELL4(SID), ELL5(SID), EVLUSID), MC(SID) and 
MCC(SID). The current absolute and expected losses accumulated are also 
read and stored In CAL2(SID) f CEL2(SID) t CEL3(SID), CEL4(SID> # and 
CEL5(SID).The ELFUNC(SID) and EVFUNC(SID) values are also set for use 

5 when calculating the expected loss and expected value for the current 
order. Block 1602 calculates the price of the order entitlement function 
using the counterparty product expected loss and expected value 
parameters ELFUNC(SID) and EVFUNC(SID). The order's expected loss 1s 
stored In EL(SID); the order's expected value Is stored In EV(SID). The 

10 absolute loss function 1s also determined at block 1602 and It 1s stored 
In AL(SID). Proceeding to block 1604, the portion of the order which 
will not violate the counterparty limits Is calculated. This check 1s 
made at test 1606. If no part of the order Is matched, process flow 
continues at block 1608. The potential counterparty Is removed from the 

15 counterparty shortlist. 

If some portion of the order Is matched with the current 
counterparty, processing continues at block 1610. Here the SID is set to 
the Identification of the matching counterparty. The unmatched portion 
(If any) is stored at block 1614 as a new order in the PORD QUEUE 

20 masterfile (block 1616). Flow then returns to test 1261 in Fig. 11. When 
a match occurs, program flow returns to block 650. The matched order 
must now be confirmed by carrying out a number of additional steps, as 
shown In Fig. 16, blocks 1620 to 1641. If no match occurred, processing 
of the current order steps, and program flow returns to the beginning 

25 via connector "A". The system is ready to load the next available order. 

Matched Order Confirmation 

For matched orders to become a contract, a number of additional 

actions are required. First, at test 1620, a check for manual 
30 authorisation Is made. If required, program flow moves to block 1621 

where authorisation requests are sent to the relevant stakeholders. 

Block 1623 then tests the replies for any rejections. If one or more 

rejections. were received, program flow continues at block 1627 where the 

order is rejected. Otherwise, flow continues at 1624. Block 1624 effects 
35 the consideration payment by creating transactions in the payment shadow 

file (PAYACC SHADOW - block 1625). However, this may fall If the 
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accounts specified do not exist or If at least the required 
consideration amount Is shown not to be available. Test 1626 checks that 
"consideration payment" was effected successfully. If "consideration 
payment" falls, the matched order 1s rejected (block 1627), with details 

5 stored In the rejected order master file, PORD REJ (block 1628). The 
ordering party Is then Informed of this event at block 1640. 

With successful payment, program flow proceeds to block 1630 where 
the counterparty's current accumulated absolute and expected loss 
figures are updated (masterflle PSEL LIMIT - block 1631). At block 1632, 

10 the order data field OPRICE 1s set to the price given by the 
counterparty PRICE(SID), and SPRICE set to the counterparty's 
Identification, SID. At block 1634, the matched order Is certified as 
confirmed, with full details recorded In the masterflle PORD CONF (block 
1636). The next step, block 1638, reports details of the newly created 

15 contingent contract to all stakeholders concerned. Program flow then 
returns to the beginning, via connector "A". The system Is now ready to 
start processing the next order submitted by a specified ordering party. 



WO 94/28496 



PCT/AU93/00250 



-35- 

6. Life Cycle of Risk Management Contract: Example III 

The third example of a risk management contract describes a 
contract to manage risk associated with potential future movements In 

5 the value of a specified Index of share prices (termed the PTSE 75 

index). In summary, the example shows how the system could enable one 
party (such as an Institutional fund manager) seeking to avoid the 
adverse consequences of a significant decline In the future value of the 
PTSE 75 Index (specifically a decline by June 1994, relative to the 

10 assumed current (January 1993) value of the Index) to make a contract 
with another, as-yet-unknown, party, such as another fund manager 
seeking to avoid the adverse consequences of a significant corresponding 
increase 1n PTSE 75 Index value. 

The specific offering 1s one which provides a contract ordering 

15 party with a specified contingent entitlement to a compensatory 

Australian dollar future payout upon payment of a calculated up-front 
consideration money amount by the ordering party to the as-yet-unknown 
counterparty. The future money entitlement 1s contingent on the value, 
at contract maturity date, of the Independently-determined value of the 

20 PTSE 75 Index. 

In this example, the relevant key stakeholders are: an application 
promoter (BLC Inc); various product sponsors (the relevant one for the 
example being BLC Inc itself); various product ordering parties (the 
relevant ones for the example being Abbotts & Taylor and Shearer & 

25 Associates); various potential counterparties (the relevant ones for the 
example being Abrahamsons and Carpenters Inc); a counterparty guarantor 
(CNZ Banking Corporation); and an application regulator (the Pacific 
Central Bank). 

The timeline depicting the steps in the contract from the first 
30 step (Application Specification) to the final step (Contract Settlement) 
is shown in Fig. 17. Appendix G contains thirteen detailed explanatory 
charts supporting Fig. 17. This Appendix should be read together with 
the following description. 

Looking at the first step In the timeline (Application 
35 Specification) In conjunction with chart G2, It can be seen that BLC Inc 
established a Contract APP (Application ID 001) on 91.06.03.17.00.00 
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(that is, 5pm on June 3, 1991) to deal with economic risk management. 
Application ID 001 supports a range of products (Applicable Product ID'S 
10020-11400). 

Looking at the second step in the timeline (Product Specification) 

5 In conjunction with chart G3, It can be seen that BLC Inc was also 
Product Sponsor of Product 10061 at the same time (91-06.03.17.00.00). 
This Product relates to the Market termed Stock Indices and to the 
Sub-market termed PTSE 75. The maturity date for Product 10061 Is 
94.06.03.17.00-00.00. The consideration fdr a specific contract 

10 Involving Product 10061 Is in the form of money (commercial bank 

deposits denominated 1n Australian dollars). The entitlement Is also in 
the form of commercial bank deposits denominated In Australian dollars, 
payable (if necessary) immediately after the Product's specified 
maturity date/ time. 

15 Looking at the third step in the timeline (Potential Counterparty 

Product Pricing Specifications), one can find two entitles, Abrahamsons 
and Carpenters Inc, acting as potential counterparties for forthcoming 
primary product orders dealing with Product 10061. At this point 1n the 
timeline (93.01.01.17.00.00.00), 19 months after the specification of 

20 Product 10061, both Abrahamsons and Carpenters Inc have 

currently-specified parameters for pricing potentially forthcoming 
orders for the product. 

Looking at the fourth step in the timeline (Primary Order 
Specification), In conjunction with chart G4, it can be seen that an 

25 Ordering Party, Abbotts & Taylor, Is seeking a contract, from an 
offering party, In Product 10061 at that time (93.01.01.17.37.06.00). 
chart G4 shows the specific parameters (entitlement) that Abbotts & 
Taylor has defined for the contract 1t is seeking at this time, 
Including a maximum acceptable contract consideration amount of 54,000 

30 (denominated in commercial bank, Australian dollars). 

In order to provide a more detailed explanation of the following 
fifth to seventh steps 1n the timeline, selected processing block 
numbers from Figs. 8-16 will be referred to in brackets as follows: 
"C 

35 Looking at the fifth step 1n the timeline (Order Specification 

Pricing) in conjunction with chart G5, 1t can be seen that Abrahamsons 1 
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speclfied pricing parameters, as set at 93.01.01.17.37.06.00 are used to 
price the Abbotts & Taylor order at 93.01.01.17.38.02.00. Abrahamsons 1 
pricing parameters Indicate that their appropriate Defined Circumstances 
ID for Abbotts & Taylor 1s 26 [1240]. As Is shown, this ID 1n turn 

5 Implies a Commission Rate of 1.25%, a Discount Rate of 10.00% per annum, 
a particular set of Component product prices and a particular set of 
Assessed Probabilities of Occurrence. In a similar process to that 
described for Example I, this results 1n a Contract Bid Price of 51,920 
(denominated in commercial bank, Australian dollars), which Abrahamsons 1 

10 parameters calculate will yield them a base margin on the contract of 
4,580 (again denominated in commercial bank, Australian dollars) [1250]. 

Still looking at the fifth step In the timeline, in conjunction 
with chart G6, it can be seen that Carpenters Inc specified pricing 
parameters, as set at 93.01.01.17.37.06.00, are also used to price the 

15 Abbotts & Taylor order at 93.01.01.17.38.02.00. Carpenters Inc's 

pricing parameters indicate that their appropriate Defined Circumstances 
ID for Abbotts 8t Taylor is 17 [1240]. As Is shown, this ID In turn 
Implies a Commission Rate of 1.30%, a Discount Rate of 9.80% per annum, 
a particular set of Component product prices and a particular set of 

20 Assessed Probabilities of Occurrence. This results in a Contract Bid 
Price of 53,050 (denominated in commercial bank, Australian dollars), 
which Carpenters Inc's parameters calculate will yield them a base 
margin on the contract of 5,610 (again denominated In commercial bank, 
Australian dollars) [1250]. 

25 Again, still looking at the fifth step in the timeline, in 

conjunction with chart G7, it can be seen that Abrahamsons 1 
pricing-related parameters (also set at 93.01.01.17.37.06.00) for 
determining the acceptability of ordered-contracts on the basis of their 
absolute loss, expected loss, expected value, and maximum portfolio 

30 composition attributes are satisfied by Abbotts & Taylor's order [1604]. 
From Abrahamsons 1 perspective, this qualifies Abbotts & Taylor's order 
for Inclusion In their product/contract portfolio, as long as 
Abrahamsons 1 consideration price bid turns out to be lower than 
Carpenters Inc's price bid, and, in turn, this bid is below the maximum 

35 consideration price that Abbotts & Taylor has specified, In its order 
specification (chart G4), 1t is prepared to pay. 
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Flnally, still looking at the fifth step In the timeline, but now 
in conjunction with chart G8, It can be seen that Carpenters Inc's 
pricing-related parameters (set at 93.01.01.17-37.06.00) for determining 
the acceptability of ordered-contract on the basis of their absolute 

5 loss, expected loss, expected value, and maximum portfolio composition 
attributes are also satisfied by Abbotts & Taylor's order. Now, from 
Carpenters Inc's perspective, this qualifies Abbotts & Taylor's order 
for Inclusion In their product/contract portfolio, in this case, as long 
as Carpenters Inc's consideration price bid turns out to be lower than 

10 Abrahamsons' price bid, and, 1n turn, this bid 1s below the maximum 
consideration price that Abbotts & Taylor has specified, In Its order 
specification (Page G4), 1t Is prepared to pay. 

Looking at the sixth step In the timeline (Order Matching), 1t can 
be found that Abrahamsons' price bid of 51,920 1s below Carpenters Inc's 

15 bid of 53,050 and, 1n turn, that the 51,920 amount 1s below Abbotts & 
Taylor's specified maximum consideration price of 54,000. This leads to 
a formal matching of Abbotts & Taylor's order by Abrahamsons' at 
93.01.01.17.38.07.00 [1260]. 

The seventh step in the timeline (Order/Contract Confirmation) 

20 takes place five seconds later at 93.01.01.17.38.11.00, after the system 
has determined that Abbotts & Taylor 1s able to (and then does) 
immediately pay the required consideration funds amount of 51,920 to 
Abrahamsons [650]. 

Looking at the eighth step In the timeline (Contract Valuation) 1n 

25 conjunction with chart G9, one can see a contract valuation report for 
Abbotts & Taylor published nearly six hours after confirmation of the 
contract, that is, at 93.01.01.23.00.00.00. As can be seen, the market 
estimate of the future product value of the PTSE 75 Index at this moment 
Is 1970 (with a standard deviation of 333), which Implies that this 

30 contract has an expected future value of 53,000 commercial 

bank-denominated Australian dollars (with a standard deviation of 
21,160). On chart G10 one can see 1n the equivalent report for 
Abrahamsons that their required expected future entitlement payout 1s 
Identical to Abbotts & Taylor's expected future entitlement receipt 

35 (Ignoring future fee payments which may be netted against these 
payments/receipts). 
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The ninth step In the timeline (Secondary Order Specification), 
detailed on chart Gil, occurs nearly six months after the 
above-described contract valuation event; that is f at 
93.06.06.08-00,00.00. At this time, Abbotts & Taylor is seeking to sell 

5 Its position In the contract which was matched/confirmed at 
93.01.01.17.38.11.00 (and at that time assigned the Order ID of 
9156515800 by the system) at a price better than 57,000. Shearer & 
Associates 1s prepared to pay 60,000 (commercial bank 
deposit-denominated Australian dollars) for this position. In all other 

10 respects the contract's attributes remain unchanged. On chart G12, the 
tenth step In the timeline, a contract sale 1s seen to have occurred at 
a price of 58,300, just below the above-described 60,000 upper limit 
purchase-price amount specified by Shearer & Associates. This amount 1s 
the current best estimate of the contract's expected future value, with 

15 the standard deviation of this expected future value calculated by the 
system, utilizing other recent transaction data, as being 10,610. 
Shearer & Associates has now formally taken the place of Abbotts & 
Taylor as a stakeholder to the contract. 

The eleventh step 1n the timeline (Contract Valuation) refers to a 

20 contract valuation report published for Shearer & Associates seven 
months later, at 94.01.01.17.00.00.00 (see chart G13). As can be seen, 
the market estimate of the future product vaMie of the PTSE 75 Index at 
this moment Is 1800 (with a standard deviation of 283), which Implies 
that this contract now has an expected future value of 162,360 

25 commercial bank deposit-denominated Australian dollars (with a standard 
deviation of 35,160). This 1s an Increase 1n expected future value of 
104,060 for Shearer & Associates since the former valuation date/time. 
The above-described market estimate of the future product value 1s 
determined by the system applying a defined composite of 

30 contract-counterparty assessed probabilities of occurrence figures drawn 
from the collection of all like contracts recently matched/confirmed by 
the system. 

The twelfth step 1n the timeline (Contract Maturity) refers to the 
actual determination of the product value at time of maturity, 
35 94.06.03.17.00.00.00. As can be seen on chart G14, this product value 
of the PTSE Index was specified by BLC Inc (as Product Sponsor) to be 
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1820, Implying a contract value of 187,200 (commercial bank 
deposit-denominated Australian dollars) to Shearer & Associates, and a 
corresponding obligation on Abrahamsons. The figure of 1820 represents 
the actual value of the PTSE share price Index at 94,06.03.17.00.00.00 
5 as obtained by BLC Inc from the Independently verifiable Information 
source, the Identity of which they would have disclosed at the time they 
first announced their sponsorship of trading 1n the PTSE 75 share Index 
product. 

The thirteenth step 1n the timeline Involves the formal payment of 
10 187,200 (commercial bank deposit-denominated Australian dollars) by 
Abrahamsons to Shearer & Associates (ignoring possible fee payments by 
one or both parties). 
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7. Description of Consideration/Entitlement Payment Process 

The purpose of the CONTRACT APP consideration/entitlement (and 
related transactions) payment/receipt process Is to effect debits and 

5 credits to INVENTCO stakeholder accounts, typically at maturity of a 
contract, with participating consideration/entitlement transfer (or 
exchange) entitles, reflecting payment/receipt entitlements and 
obligations originated within INVENTCO. The process effects these 
payments/receipts In a two-stage process. First, by debiting/crediting, 

10 on a real-time basis, the relevant shadow records (In the data file 
PAYACC SHADOW) of the applicable stakeholder accounts with a 
participating consideration/entitlement transfer entity (C/E entity), 
external to INVENTCO, with which they maintain an account. And second, 
by periodically effecting, via existing and potential payment 

15 mechanisms, corresponding payment Instructions to the payment entitles 
concerned. Details of the above-described mechanism are as follows. 

All INVENTCO stakeholders maintain (a minimum of) two 
special-purpose (net-credit balance only) accounts with (at least) one 
selected, VIRPRO authorised, C/E transfer entity. The purpose of 

20 special-purpose accounts Is to ensure that only INVENTC0-1n1t1ated 
debits and credits are capable of being effected to the accounts. Thus, 
at any time the balance of each PAYACC SHADOW file account record should 
be equivalent to the true, but usually unknown, time-of-day balance of 
the actual account maintained by the C/E transfer entity. 

25 The purpose of two accounts Is to enable only credits to be 

effected through one account and only debits through another account. 
And the purpose of "net-credit balance only" accounts 1s to ensure that 
accumulated debits to the debits-only account never exceed the account 
opening balance plus accumulated credits to the credits-only account. 

30 C/E transfer entitles will typically be (but do not need to be) 

Institutions of any/all of six types: public/private record-registries 
of various types; credit card companies (typically for retail 
transactions only); commercial banks; central banks; taxation 
authorities; and non-bank clearing houses and depositories. 

35 The resources transferred by these entitles may be of any type. 

However, most typically, they will be deposits appropriate for the 
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entlty concerned: With respect to public/private record-registries - 
entitlement deposits (Including shares In financial or physical assets, 
participation rights In wagers, and so on). With respect to credit/debit 
card companies - normal card company deposits (denominated In national 

5 currencies or synthetic currencies (for example, SDRs)). With respect to 
commercial banks - normal bank deposits (denominated In national 
currencies or synthetic currencies (for example, SDRs)). With respect to 
central banks - exchange settlement account (or equivalent) deposits. 
With respect to taxation authorities - taxation account deposits. And 

10 with respect to non-bank clearing houses and depositories - deposits of 
financial Instruments, precious metals and the like. CONTRACT APP 
potential counterparties will also effectively be C/E transfer entitles, 
as will ordering party guarantors (external to INVENTCO) where they 
offer credit to product ordering parties. Also, some accounts will be 

15 trust accounts maintained on behalf of potential counterparties (and 
some product ordering parties) Involved In applications requiring the 
periodic payment of collateral to Independent third parties to serve as 
an additional security device. 

Immediately after the completion of Its dally - or more frequent - 

20 transaction processing, and their associated settlement functions, each 
C/E transfer entity electronically notifies the applicable CONTRACT APP 
of the "opening balances" of all the debit and credit INVENTCO accounts 
it maintains (At this stage, the debit account balance should be zero 
and the credit account balance should be greater than or equal to zero). 

25 Where an INVENTCO stakeholder has an overdraft or llne-of-credlt with 
Its C/E transfer entity, the credit value of this will be reflected 1n 
the non-zero balance of Its credit account at this time. 

Upon receipt of the above-described notifications, the applicable 
CONTRACT APP updates/confirms its stakeholder shadow balances. Thus, at 

30 this polnt-in-tlme, all credit and debit shadow account balances should 
be equivalent to their actual debit and credit account balances. 

Progressively throughout the day (where "day" here Is likely to be 
different for each C/E transfer entity due to a combination of 
differences in the time-zone locations of payment entitles in relation 

35 to the applicable CONTRACT APP, and the likely different account 

processing cycles of these entitles), INVENTCO-stakeholder- authorised 
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deblts and credits to INVENTCO stakeholder shadow accounts are effected 
on a real-time basis - debits to debit accounts and credits to credit 
accounts. At all times, the CONTRACT APP ensures that the cumulative 
debit balance of each stakeholder's debits account does not exceed the 

5 "opening balance" plus the cumulative credit balance of the 

stakeholder's credit account. Thus, at any time, for every INVENTCO 
stakeholder, the combination of each stakeholder's debit account and 
credit account will represent the "true", net, time-of-day value of the 
stakeholder's two actual special-purpose accounts maintained external to 

10 INVENTCO. 

Debits and credits to INVENTCO stakeholder accounts are effected 
according to strict rules and conditions, being different for credits 
and debits. Credits can be made to any INVENTCO stakeholder's credit 
account with Its nominated C/E transfer entity by any other INVENTCO 

15 stakeholder for any reason. Naturally, as INVENTCO stakeholders will not 
know the account details of other stakeholders, such credits will be 
effected either automatically, according to Information and rules known 
by the applicable CONTRACT APP, or semi -automatical ly by way of an 
INVENTCO stakeholder requesting from VIRPRO, as they need to do so, a 

20 credit-account number of the stakeholder to which they wish to transfer 
assets. This account number may only be valid for a nominated period and 
would not typically be the specified stakeholder's actual account number 
with Its nominated consideration/entitlement transfer entity - it would 
only be a reference to an INVENTCO file containing this number. 

25 On the other hand, debits can only be made to an INVENTCO 

stakeholder's debit account with Its nominated C/E transfer entity by 
the stakeholder itself, and by other stakeholders explicitly granted 
this right by each stakeholder, subject to these other stakeholders 
exercising this right according to the rules and conditions specified 

30 for them. 

Where an INVENTCO stakeholder seeks to Initiate/authorise debits 
to its nominated account(s) on Its own, this can only be done through 
the stakeholder satisfactorily completing the identification and 
security procedures set down by their C/E consideration/entitlement 
35 transfer entity (and reflected in VIRPRO-spedfied INVENTCO 

communication procedures). The type of procedure set down by all 
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participating C/E transfer entitles involves (at least) the following: 
First, the consideration/entitlement transfer entity supplying VIRPRO 
with a confidential file of account Pin numbers corresponding to each of 
Its INVENTCO stakeholder debit accounts, and a similarly confidential 

5 "black box" which, by initiating any of a number of possible proprietary 
password request-response processes involving any one of its customers 
possessing the appropriate device(s), confirms that remote messages 
received from that customer, and processed by the "black box", are 
authentic. Second, the consideration/entitlement transfer entity 

10 supplying their INVENTCO customers with a programmable smart card (or 
equivalent device) enabling each customer, remotely - via telephone or 
direct computer line, to unambiguously confirm their identity with their 
INVENTCO-maintained account, thereby having the capability to authorise 
debits to their account within predefined parameters concerning factors 

15 such as maximum transaction amounts, possible transaction types, account 
usage patterns and so on. Third, INVENTCO providing the mechanisms for 
direct, confidential, stakeholder communications with their C/E transfer 
entity shadow debit accounts, and the formal updating of these accounts, 
through non real-time processes, utilizing the unique time-stamped 

20 reference numbers created as/when stakeholders authorise access to their 
account records. 

Where an INVENTCO stakeholder has authorised other INVENTCO 
stakeholders to Initiate debits to (any of) its nominated account(s) 
according to a standing authority of some type, this can only be done 

25 through the authorised stakeholder itself satisfactorily completing the 
identification and security procedures set down by the 
authorisation-granting stakeholder's nominated C/E transfer entity (and 
reflected in VIRPRO-specified INVENTCO communication procedures). Once 
again, the type of procedure, set down by all participating C/E transfer 

30 entities in this respect, involves (at least) the following: First, the 
C/E transfer entity supplying VIRPRO with a confidential file of account 
Pin numbers corresponding to each of its INVENTCO stakeholder debit 
accounts and each other INVENTCO stakeholder which has been authorised 
to effect debits (within defined parameters) to these accounts. Second, 

35 the C/E transfer entity supplying VIRPRO with a similarly confidential 
black box which, by initiating any of a number of possible proprietary 
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password request-response processes involving an entity nominated by any 
of its customers possessing the appropriate devlce(s), confirms that 
remote messages received from that authorised entity, and processed by 
the black box, are authentic- Third, the C/E transfer entity supplying 

5 their INVENTCO customers with a collection of programmable smart cards 
(or equivalent devices), for distribution to these authorised entitles, 
enabling each authorised entity, remotely - via telephone or direct 
computer line - to unambiguously confirm their Identity with the 
customer's PAYACC SHADOW account, thereby having the capability to 

10 authorise debits to this account (again, within predefined parameters 
concerning factors such as maximum transaction amounts, possible 
transaction types, account usage patterns and so on). And four, INVENTCO 
providing the mechanisms for direct, confidential, authorised 
stakeholder communications with a stakeholder's C/E transfer entity 

15 shadow debit account(s). 

At the end of each C/E transfer entity's specified day (or part of 
a day), the applicable CONTRACT APP transfers (at least) two things to 
the entity: First, if required, a series of figures representing the 
exchange settlement (or equivalent) accounting entries it has or will 

20 communicate to the C/E transfer entity's appropriate clearing authority 
(for each of the applicable consideration/entitlement denomination, 
currency and national currency types of the -payments/receipts Involved) 
where these figures represent the balancing net debit or credit figure 
corresponding to the aggregation of all of the entity's INVENTCO 

25 customer transactions In the prior day. And second, a detailed file of 
all customer transactions effected during the day (corresponding, 1f 
required, to the above-described net figures). Upon their receipt of 
these transactions and summary figures, the C/E transfer entity then 
debits/credits each transaction to the appropriate actual customer 

30 accounts, enabling new "closing" account balances to be calculated 
(these "closing" balances should be exactly the same as the end-of-day 
balances commumlcated by the applicable CONTRACT APPS with It's file of 
customer transactions). In turn, these "closing balances" become the C/E 
transfer entity's account "opening balances." for the next day. The 

35 CONTRACT APPS notification process then repeats itself . 

Where applicable, at days-end for the "clearing house" of clusters 
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of like C/E transfer entitles (for example, a national central bank), 
CONTRACT APP transfers netted exchange settlement accounting entries to 
the clearing houses concerned. These entries serve to "balance the 
Individual customer account entries transferred to each associated C/E 
5 transfer entity Individually. 

8. industrial Applicability 

The Invention has Industrial application in the use of electrical 
computing devices and data communications. The apparatus and methods 
10 described allow the management of risk in an automated manner by means 
of programming of the computing devices. The types of events associated 
with the risk management apparatus and methodologies includes physical 
and technical phenomena, and therefore have value in the field of 
economic endeavour. 
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APPENDIX A 

GLOSSARY OF KEY TERMS 
5 A. 

Alpha (X) 

The Ordering party-specified event value corresponding to the Xth 
10 future product event value contract entitlement payoff (payout) 

Inflection point. 

Application Promoter 

15 An entity authorised by VIRPRO that specifies and administers 

defined rules and regulations underlying a defined CONTRACT APP - 
Including the specific products offered for trading; categories 
of, and conditions of Involvement, of stakeholders; nature of 
Involvement and dispute resolution procedures of stakeholders* 

20 

Automatic/manual deal and no deal flags 

Indicators notified by each stakeholder to CONTRACT APP specifying 
the manner in which that stakeholder wishes to deal with each 
25 other stakeholder* 

AXSCO 

A communications co-ordination and security system, linked to all 
30 stakeholders and component applications. 

B. 

Base Pricing probabilities 

35 

The prices set by sellers for unit entitlement payoffs of a 
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contract at each of Its possible future index values denominated 
In the contract's formally specified consideration/entitlement, 
currency and national currency. 

5 Beta (X) 

The Ordering party-specified desired entitlement payoff (payout) 
amount In the desired currency denomination of contract 
entitlement payout (payoff) and national currency denomination of 
10 contract entitlement payout (payoff) corresponding to the Xth 

event value inflection point. 
Bilateral Obligations Netting Indicator 

An Indicator that Individual 'rolling' net present values of 
15 future payment/receipt commitments to/from all pairs of 

participating stakeholders are to be netted. 

Bilateral Payments Netting Indicator 

20 An Indicator that individual end-of-day gross payments/receipts 

to/from all pairs of participating INVENTCO stakeholders are to be 
netted. 

C. 

25 

Commission rate 

The minimum required percentage profit margin required by a 
Potential Counterparty above the "breakeven" bid price for an 
30 Ordering party purchase order. 

Consideration/Entitlement Transfer Entity 

An entity acceptable to VIRPRO and the Application Promoter, 
35 satisfying defined minimum standards of financial strength, credit 

standing and integrity, able to maintain Consideration/entitlement 
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accounts on behalf of stakeholders and effect transfers of those 
assets as directed. 

CONTRACT APP stakeholder types 

5 

Expected stakeholder types are Application Promoter, Product 
Sponsor, Product Ordering party, Counterparty, 
Counterparty-Guarantor, Regulator, Consideration/entitlement 
Transfer Entitles and Miscellaneous other parties. 

10 

Contract and Product "absolute loss" limit 

A value limit specified by a potential counterparty of the maximum 
absolute loss It is prepared to sustain on a contract/product 
15 Irrespective of the assessment of the likelihood of any particular 

level of possible loss being Incurred. 

Contract and Product "expected loss" limit 

20 A value limit specified by a potential counterparty of the maximum 

expected loss 1t Is prepared to sustain on a contract/product 
based on the counterparty's assessment of the likelihood of all 
levels of possible loss being incurred. 

25 Contract Authorisation 

A process of verifying that an Ordering Party product purchase 
order contains data appropriate to the product being sought and 
that the Ordering Party 1s accurately Identified and credential led. 

30 

Contract Collateralisatlon Indicator 

A descriptor set by the Application Promoter specifying whether 
and on what basis, counterparties may be required to periodically 
35 transfer assets/monies (collateral) to an Independent trust fund 
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to ensure they will be able to meet their potential entitlement 
payoff obligations on the maturity date of a contract.. 

Contract Confirmation 

5 

The process of securing the positive agreement of all affected 
stakeholders to a purchase order, Including acknowledgement by the 
relevant Consideration/entitlement transfer entity of the Ordering 
party's ability to pay the required product consideration and 
10 fees, either automatically or through manual approvals. 

Contract Matching 

See Ordering party/Potential counterparty matching process. 

15 

Contractual Obligation 

a* A binding commitment one entity (or group of entities) has 
to provide products or services or Information to another entity 
20 (or group of entitles) in exchange for an agreed quantity of 

other products, services or Information. 



b. A binding commitment all entitles have to the network and 
general management system entity VIRPRO and thus to each other, to 
25 accept constraints on their activities Imposed by other authorised 

entitles on terms specified and agreed to by them as a condition 
of their participation in one or more of the component systems. 

Contract Portfolio Netting 

30 

A term used to describe the process of "setting-off" or 
"netting", the future payment entitlement obligations between 
Ordering parties and Counterparties, either bl-laterally or 
multi-lateral ly. 
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Currency and National Currency exchange rates 

The rates used to convert contract consideration/entitlement 
currency and national currency requirements Into the product's 
5 consideration/entitlement currency and national currency 

denoml nation. 

D. 

10 Deal flag 

An Indicator or "flag" notified to CONTRACT APP signifying that 
the stakeholder 1s satisfied to deal unreservedly with the 
stakeholder against whom the flag has been set. 

15 

Defined Circumstances 

The possible combinations of the categories of product-order 
Information provided by Ordering parties. 

20 

Defined Probability Distributions 

A set of pricing probability parameters specified by an Ordering 
party and Including at least, a probability distribution type 
25 Identifier, the expected value of the distribution, the standard 

deviation of the distribution and a probability distribution 
adjustment value or function. 

Desired Currency Denomination of Contract Entitlement 

30 

A term Indicating the currency 1n which an Ordering party wishes 
to receive potential entitlement payments from the sought contract. 

Desired Currency Denomination of Consideration Payment 

35 

A term Indicating the currency In which an Ordering party wishes 
to pay the required consideration for the contract sought. 
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Desired National currency Denomination of Contract Entitlement 

A term Indicating the National currency In which an Ordering party 
5 wishes to receive potential entitlement payments from the sought 

contract. 

Desired National currency Denomination of Consideration Payment 

10 A term Indicating the National currency In which the Ordering 

party wishes to pay the required consideration for the contract 
being sought. 

Discount rate 

15 

The rate used to determine the present value of a potential 
counterparty's expected future entitlements. 

E. 

20 

Entitlement 



The payout expected by the offering party at maturity as specified 
for each outcome In the range of outcomes. The payout can be both 
25 positive and negative In value over the range of outcomes, and can 

be In the form of money or other non-money types of goods, 
services, promises, credits or warrants. 

EV-CE pricing 

30 

A price discovery mechanism for primary contracts meaning 
"expected value certainty equivalent pricing" being the calculated 
expected present value or future value of the contract. 



WO 94/28496 



PCT/AU93/00250 



~ 53 - 

Expected Value 

A function in EV-CE pricing which means the sum of the products of 
all possible contract entitlement payoff /payout amounts and the 
5 Ordering party's/Counterparty's assessment of the probability of 

occurrence of the future events which would contractually give 
rise to these entitlement payoff amounts. 

Expected value limits on a Counterparty's aggregate product portfolio 

10 

Optional value limits specified by a Potential counterparty at 
any one time, where time can be specified in terms Including 
"equivalent maturity date"; "same-month maturity date" and "all 
possible maturity dates" including product expected loss limits 
15 and maximum (and possibly minimum) proportion of the expected 

total loss of the aggregate of the Counterparty's product 
portfolio that can be accounted for by the expected loss on the 
Individual contract/product. 

20 G. 

Gamma(X) 

The Ordering party-specified desired shape of the function between 
25 each of the co-ordinates Alpha(l), Beta(l) and Alpha(2>, Beta(2) 

and so on; such that Gamma can represent all possible 
mathematically definable shapes. 

I. 

30 

I-INVENTCO 



The. Infrastructure component of INVENTCO. 
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INVENTCO 

A collection of one or more (potentially Interrelated) systems, where 
each system 1s the combination of a telecommunications, computing and 
5 other forms of infrastructure, and a variety of markets and support 
services distributed by this infrastructure. 

M. 

10 M-INVENTCO 

A depository of VIRPRO authorised "markets" application software. 
Manual deal flag 

15 

An indicator or "flag" notified to CONTRACT APP by a stakeholder 
signifying that the stakeholder wishes to manually approve a 
transaction involving the other stakeholder against whom the flag 
has been set. 

20 

Multilateral Payments Netting indicator 

An indicator that individual end-of-day gross payments/receipts 
to/from all participating stakeholders from/to a specified third 
25 party trustee/clearing entity are to be netted. 

Multilateral Obligations Netting Indicator 

An indicator that individual 'rolling 1 net present values of 
30 future payment/receipt commitments to/from all participating 

stakeholders from/ to a third party trustee/clearing entity are to 
be netted. 
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N. 

Negative Contract Payoffs 

5 A type of contract In which the contract Ordering party may have a 

contingent payoff to the contract's Potential counterparty (I.e. 
the reverse of a normal contract). 

No Deal flag 

10 

An Indicator or "flag" notified to a CONTRACT APP by a stakeholder 
signifying that the stakeholder does not wish to deal In any way 
with the other stakeholder against whom the flag has been set. 

15 0. 

Ordering party Contingent Claims Function 

Specifications of a product payoff or a mathematical function to 
20 calculate an Ordering party's product payoff requirement. 



Portfolio Product "expected loss" limit 

25 

A value limit, specified by a potential Counterparty, of the 
maximum expected loss- the potential Counterparty is prepared to 
sustain on its product portfolio based on the Counterparty's 
assessment of the likelihood of all levels of possible loss being 
30 Incurred. 

Product Ordering party 

An entity acceptable to VIRPRO and the Application Promoter, 
35 Interested in and able to acquire a CONTRACT APP product. 



i 
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Product Establishment date/time 

The date/time an Application Promoter first offers a defined 
product for trading. 

5 

Product future event value "density" indicator 

An indicator specifying the number of Intermediate points between 
the minimum and maximum future event product definition values 
10 specified for the product by the Application Promoter /Product 

Sponsor, 

Product event value "width" Indicator 

15 An indicator specifying the range (minimum-maximum) of future 

event values accommodated by the product as set by the Application 
Promoter/Product Sponsor. 

Product future event value 

20 

A term used to indicate the actual value of a defined product at 
its date/time of maturity. 

Product Maturity date/time 

25 

The date-time at which the Application Promoter is required to 
make a determination of the actual event value to enable 
entitlement and related payoffs on successful contracts. 

30 Product Price Quote requests 



A type of product purchase order for which the matching process is 
terminated and the result communicated to the Ordering party, 
when a desired price bid or range of price bids has been obtained. 



WO 94/28496 



PCT7AU93/00250 



- 57 - 

Product Purchase Orders 

Specific product purchase orders for which the Ordering party Is 
seeking a potential Counterparty match, which may be of three 
5 types: automatic orders; manual orders and "hide" orders. 

Product Purchase Order withdrawals 

Ordering party-Initiated requests to withdraw from processing 
10 pre-subm1tted but as yet unconfirmed product purchase orders. 

Product potential Counterparty 

An entity acceptable to VIRPRO and the Application Promoter, 
15 exceeding a defined minimum standard of financial strength, credit 

standing and Integrity, offering defined CONTRACT APP products to 
product Ordering parties. 

Product Sponsor 

20 

An entity acceptable to VIRPRO and the Application Promoter, 
having responsibility for detailed definition of product 
parameters Including the continual determination of product values 
over time. 

25 

R. 

Regulator 

30 An entity acceptable to VIRPRO having local, state, national or 

International jurisdiction over one or more CONTRACT APPS. 
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S. 



Set of Pricing Probabilities 

5 

The range of probabilities a potential Counterparty applies to a 
class of Ordering party order, specified by the value of "defined 
circumstances" and applying to every feasible future product event 
defined for that product by an Application Promoter. 

10 

Stakeholder 

An entity that Is a registered participant in one or more of 
INVENTCO's component parts. 

V. 

Value Dates 

20 The respective dates/times at which matched contract consideration 

and entitlements are agreed to be made by the relevant Ordering 
party /Counterparty to a contract. 

VIRPRO 

25 

The network and general management system component of INVENTCO. 

30 "X" 

A term Indicating the number of contract payoff (payout) 
Inflection points the Ordering party Is seeking within the 
allowable range of future product event values (including the 
35 value range extremity points). 
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APPENDIX B 

CONTRACT APPS 

5 Overview 

CONTRACT APPS Is a term used to refer to certain types of units of 
applications software which can, but do not need to, reside within an 
INVENTCO system's (M-INVENTCO) depository of "markets" software. The 
purpose of individual CONTRACT APPS 1s two-fold: First, to effect the 

10 trading/exchange/transfer of risk aversion transactions (and derivatives 
of these transactions) between participating ordering parties and 
counterparties on terms acceptable to the parties involved as well as to 
others within INVENTCO registered as having a legitimate Interest 1n the 
nature, size and composition of these trades/exchanges/transfers. And 

15 second, to appropriately manage all matched/confirmed contracts through 
to their time of maturity, Including their ultimate settlement. 

Individual CONTRACT APPS perform theses tasks according to the 
specific rules they embody, defined by their own stakeholders. CONTRACT 
APPS effectively reside upon AXSCO and within M-INVENTCO. 

20 

Stakeholder Types 

CONTRACT APPS accommodate eight (and potentially fewer) generic 
types of their "own" stakeholders (as distinct from other INVENTCO 
stakeholders) termed: application promoter, product sponsors, product 

25 ordering parties, potential product counterparties, 

counterparty-guarantors, regulators, consideration/entitlement transfer 
entities, and other miscellaneous parties. 

Some details of these stakeholders are as as follows: an 
appl 1 cation promoter is an entity having overall responsibility for the 

30 functioning of a CONTRACT APP (that responsibility having been granted by 
VIRPRO); a product sponsor Is an entity which promotes and administers 
the rules of trading, and subsequent management, of defined contingent 
claims contracting product(s) selected for inclusion In a CONTRACT APP by 
its application promoter; a product ordering party is an entity seeking 

35 to acquire a CONTRACT APP product from a potential product counterparty 
(where a product ordering party can also be a product counterparty); a 
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potentlal product counterparty is an entity potentially prepared to 
satisfy the CONTRACT APP product needs of a product ordering party (where 
a potential product counterparty can also be a product ordering party); a 
counterparty-guarantor Is an entity guaranteeing a product counterparty's 

5 ability to settle any /all of its potential entitlement transfer 
obligations to a product ordering party to which it has become a 
counterparty as a result of a CONTRACT APP effected "match"; regulators 
are entities overseeing the on-going performance of all other 
stakeholders involved In a CONTRACT APP, especially 

10 counterparty-guarantors; consideration/entitlement transfer entitles are 
entitles with which all other CONTRACT APP stakeholders maintain 
"accounts" to transfer required considerations/entitlements to/from all 
each other; and miscellaneous parties are all other entitles having a 
defined stake 1n the functioning of a CONTRACT APP. 

15 Miscellaneous parties include: independent entities contracted by 

application promoters or product sponsors to formally determine the 
"value" of products on their date-of-maturity; multilateral obligations 
and payment netting trustee/clearing entity organisations; independent 
(non-regulator) taxation and other governmental authorities; electronic 

20 "gateway" providers (external to INVENTCO); and host system organizations 
(in the case of CONTRACT APPS within INVENTCO systems linked to a common 
host system). CONTRACT APPS accommodate any number of their own 
stakeholders of each of the above-defined generic types. 

25 Product Tvoes 

CONTRACT APPS can support risk aversion contract "product types" 
with any combination of values of multiple attributes, Including: the 
fundamental nature/purpose of the product; the establishment/maturity 
date/time of the product; the consideration/entitlement denomination 

30 type, currency (if applicable), and national currency (if applicable) 
consideration/entitlement Identifiers associated with the product; the 
"width" and "density" identifiers of possible future event values of the 
product; and miscellaneous other product descriptors. 

The "fundamental nature/purpose of the product" attribute may 

35 Incorporate Identifiers including: a conditional entitlement-payoff 

dimensioins identifier; a market identifier; a sub-market identifier; and 
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a market-type Identifier. The "conditional entitlement-payoff dimensions 
Identifier" specifies the number of dimensions to an ordering party's 
sought-after conditional entitlement-payoffs. The market identifier 
specifies whether the product relates to an "actual" or "perceived" 

5 phenomenon (or phenomena), the number of such phenomena (If applicable), 
and the applicable phenomenon category (for example, Industrial, 
scientific, financial market hedging, and so on). The sub-market 
Identifier provides a more specific description of the product concerned. 
The market-type Identifier specifies the applicable future period 

10 date/time (where this can be anything - for example, "at a defined 

contract maturity date/time", "at a specified time on or before contract 
maturity date/time", and so on), and type-of-future event involved 
(where, again, this can be anything - for example, as an Indicator of 
some relative value of a phenomenon (spot value, average value and so 

15 on), or as an Indicator of the "rate-of-change" of some value of a 
phenomenon. 

The "establishment and maturity date/time of the product" attribute 
specifies, respectively, the date/time an application promoter first 
offered a product for trading, and the date/time at which the defined 

20 product matures (that is, the date/time at which the product sponsor is 
required to make a determination of the actual event value at that 
date/time so enabling contract entitlement transfers to be effected). 

The "consideration/entitlement denomination type, currency (if 
applicable), and national currency (if applicable) 

25 consideration/entitlement identifiers associated with the product" 

attribute specify: the type of consideration/entitlement Involved (where 
this can Include rights and entitlements, physical assets, and "money" of 
all possible types); in the case of a "money" consideration/entitlement 
type, the currency of the consideration/entitlement (where such currency 

30 types can Include: public/private record-depository deposits, commercial 
credit card company deposits, commercial bank deposits, central bank 
deposits, taxation authority deposits, and deposits In non-bank clearing 
houses arid. depositories, and the like); and, again, 1n the case of a 
"money" consideration/entitlement type, the national currency of the 

35 consideration/entitlement identifier (where such national currency types 
can be in any national currency, or form of synthetic currency). 
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The "width and density Identifiers of possible future event values 
of the product" attribute specifies, respectively: the minimum and 
maximum values of the allowable range of future event values accommodated 
by a product; and the number of intermediate points between the defined 

5 minimum and maximum future event values accommodated by the product. 

The "miscellaneous other product descriptors" attribute specifies 
such things as: the degree of stakeholder access granted the product by 
the application promoter 1n question; the forms of trading-services 
granted the product by the application promoter 1n question (where this 

10 product attribute specifies the accessibility of the product to a range 
of feasible "stakeholder services" with respect to such things as 
contract portfolio netting, contract collateralisation, consideration 
credit provision, ordering party ability to specify negative contract 
entitlements, and availability of secondary /derivative market product 

15 trading) ; and the degrees of trading, clearing and settlement 
"transparency" granted the product by the application promoter in 
question. 

Transaction Types 

20 A range of primary, secondary, derivative-primary, and 

derivative-secondary risk aversion contract transactions are accommodated 
by CONTRACT APPS. 

The range of "primary" (and derivative-primary (options, for 
example)) risk aversion contract transact Ion- types (handled principally 

25 by Processes 2 and 4 - described In Appendix C) include: ordering party 
product orders (and option orders) for which the ordering party is 
seeking a counterparty "match", order ing-party price quote (and options 
price quote) requests; and order ing-party withdrawals of existing product 
orders (and withdrawal of options on product orders). Ordering party 

30 product orders consist of: automatic orders and manual orders. Automatic 
orders consist of: normal -automatic orders (being orders the ordering 
party is prepared to have matched automatically, subject only to the 
constraints defined in the ordering party's order, in addition to 
whatever "match" constraints other CONTRACT APP stakeholders have 

35 prespecifled); and anonymous-automatic orders (being orders the ordering 
party is prepared to have matched automatically, subject to the 
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constralnts defined in the ordering party's order, In addition to 
whatever "match" constraints other CONTRACT APP stakeholders have 
prespedfled, provided that no CONTRACT APP stakeholder has sought to 
manually authorise the transaction and, through so doing, being able to 

5 potentially identify the ordering party). Manual orders consist of 

normal-manual orders (being orders the ordering party wishes to manually 
authorise before they are finalised - that 1s, after a counterparty 
"match" has been effected but before the contract has been "confirmed" - 
subject only to the constraints defined In the ordering party's order, In 

10 addition to whatever "match" constraints other CONTRACT APP stakeholders 
have prespedfled); and anonymous-manual orders (being orders the 
ordering party wishes to manually authorise before they are finalised - 
that 1s, after a counterparty "match" has been effected but before the 
contract has been "confirmed" - subject to the constraints defined In the 

15 ordering party's order, in addition to whatever "match" constraints other 
CONTRACT APP stakeholders have prespedfled, provided that no CONTRACT 
APP stakeholder has also sought to manually authorise the transaction 
and, through so doing, potentially Identify the ordering party). 

The range of "secondary" (and derivative-secondary (options, for 

20 example) risk aversion contract transaction-types (handled principally by 
Processes 3 and 5 - described in Appendix B) include: acquiring party 
product orders (and option orders) for which the acquiring party Is 
seeking to "acquire" the position of a specified "risk counterparty" 
stakeholder In an existing contract; acqul ring-party product price 

25 indications (and option price indications); and acqul ring-party 
withdrawals of existing product orders (and option withdrawals). 

Acquiring party product orders for which the acquiring party is 
seeking to "acquire" the position of a specified "risk counterparty" 
stakeholder In an existing contract, consist of automatic orders and 

30 manual orders. 

Automatic orders consist of: normal -automat 1c orders (being orders 
the acquiring party is prepared to have matched automatically, subject 
only to the constraints defined In the acquiring party's order, in 
addition to whatever "match" constraints other CONTRACT APP stakeholders 

35 have prespedfled); and anonymous-automatic orders (being orders the 
acquiring party 1s prepared to have matched automatically, subject to the 
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constralnts defined In the acquiring party's order, 1n addition to 
whatever "match" constraints other CONTRACT APP stakeholders have 
prespeclfled, provided that no CONTRACT APP stakeholder has sought to 
manually authorise the transaction and, through so doing, being able to 

5 potentially Identify the acquiring party). 

Manual orders consist of normal-manual orders (being orders the 
acquiring party wishes to manually authorise before they are finalised - 
that is, after a "match" has been effected but before the contract "sale" 
1s "confirmed" - subject only to the constraints defined in the acquiring 

10 party's order, In addition to whatever "match" constraints other CONTRACT 
APP stakeholders have prespeclfled); and anonymous-manual orders (being 
orders the acquiring party wishes to manually authorise before they are 
finalised - that is, after a "match" has been effected but before the 
contract "sale" is "confirmed" - subject to the constraints defined in 

15 the acquiring party's order, in addition to whatever "match" constraints 
other CONTRACT APP stakeholders have prespecifled, provided that no 
CONTRACT APP stakeholder has also sought to manually authorise the 
transaction and, through so doing, potentially identify the acquiring 
party)* 

20 

Primary Product Pricing Process Types 

CONTRACT APPS enable potential counterparties to automatically 
establish "bids" on any defined (primary and derivative-primary) product 
order according to either an "expected value/utiHty-certainty 

25 equivalent" (EV/U-CE) pricing regime, or any other 
mathematically-definable pricing regime. 

In the case of an "expected value-certainty equivalent" (EV-CE) 
pricing regime, each potential counterparty specifies, amongst other 
things: an indicator of certain defined attributes of an as-yet-unknown 

30 product order; a base commission rate; a base discount rate; (if 
applicable) a set of base consideration/entitlement denomination, 
currency, and national currency exchange rates; base unit product prices; 
and desired adjustments to the preceding base-bid-price determinants 
dependent on any specific order (submitted by a specified ordering party). 

35 The above-described indicator of certain defined attributes of an 

as-yet-unknown .product order (termed, defined circumstances) may reflect 
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any combination of the multiple characteristics of an order (Irrespective 
of the ordering party concerned), Including: the multiple attributes of 
the contingent claims function sought; the ordering party's Interest or 
otherwise 1n being granted credit by a counterparty; the ordering party's 

5 interest or otherwise In participating In the possible netting and 
collaterallsatlon features of the APP; and the maximum (and possibly 
minimum) consideration amount the ordering party Is prepared to pay for 
their defined product. The above-described base commission rate specifies 
the minimum required percentage profit margin required by the 

10 counterparty above their breakeven consideration bid price for a product 
order. 

The above-described base discount rate determines the present value 
of the counterparty's expected future entitlement associated with a 
contract (net of the ordering party's consideration, and making allowance 

15 for the future Income stream this consideration 1s expected to generate). 
The above-described set of base consideration/entitlement denomination, 
currency and national currency -exchange rates are used, where applicable, 
to convert an ordering party's contract requirements into the base 
consideration/entitlement denomination, currency and national currency of 

20 the product so enabling the contract matching process to make like 
comparisons of counterparty bids for product orders. 

The above-described base unit product prices are prices set by 
potential counterparties for unit entitlement-payoffs of a contract at 
each of its possible future values, denominated In the contract's 

25 formally specified consideration/entitlement type and, If applicable, 
currency type and national currency type (where these unit prices can be 
specified as directly input -figures for every feasible future product 
event (the sum of which may or may not add to 1), or as parameters of 
defined mathematical functions). The above-described desired adjustments 

30 to the preceding base-bid-price determinants dependent on the specific 
ordering party submitting a specific order can Include: a commission rate 
adjustment; a discount rate adjustment; a consideration/denomination 
exchange rate adjustment; a currency exchange rate adjustment; and a 
national currency exchange rate adjustment. 

35 In the case of an "expected utility-certainty equivalent" (EU-CE) 

pricing regime, each potential counterparty specifies all of the 
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above-descrlbed parameters applicable to a EV-CE pricing regime as well 
as "utility bench-mark" figures for all possible consideration and 
entitlement "payment amounts" which could, conceivably, be associated 
with a product/contract. 

5 

Primary Product Matching Process Types 

CONTRACT APRS may similarly accommodate any of a number of possible 
(primary and derivative-primary) order matching processes where these 
processes can be of multiple types, including sequential processes and 

10 simultaneous processes. 

Sequential order matching processes can be characterised according 
to the "sequence determining" and "matching" rules they embody, where 
"sequence" rules may be of various types: "last-1n-f1rst-out (LIFO)", 
"first-ln-flrst-out" (FIFO)", priced priority, and so on; and matching 

15 rules may also be of various types - for example, a specific matching 
process could seek, for each product ordering party, a counterparty (or 
counterparties) offering a product price at or below the maximum price 
the ordering party Is prepared to pay (where the determined contract 
price could be either the lowest price offered by a potential 

20 counterparty, the mid-point between the an ordering party's specified 
"maximum consideration amount" and the lowest price offered by a 
potential counterparty, and so on); or seek for each potential product 
counterparty an ordering party prepared to pay the maximum price above a 
price at which the counterparty is prepared to deal (here, the determined 

25 contract price could be either: the ordering party's "maximum 

consideration amount " price, the mid point between the minimum price the 
counterparty 1s prepared to receive and the ordering party's "maximum 
consideration amount" price, and so on). 

Simultaneous order matching processes are those seeking some type 

30 of optimum solution according to pre-defined objectives. For example: 
"maximise the number of ordering party-counterparty matches"; "maximize 
the aggregate consideration and/or entitlement value of ordering 
party-counterparty matches"; or "minimize the value of a function 
specifying the sum of the differences (possibly weighted according to 

35 their perceived Importance) between the actual and desired values of 
match attributes of ordering parties and counterparties". 
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Both of the above-described sequential and simultaneous matching 
processes can also accommodate conditional contract matching rules; and 
pre and post tax price optimisation mechanisms. 

5 Application Types 

CONTRACT APPS may be: "1n-house n APPS or "public" APPS; "single 
potential counterparty" APPS or "multiple potential counterparty" APPS; 
APPS with differing degrees and forms of "regulator" oversight of other 
application stakeholders; and APPS with differing degrees and forms of 

10 "counterparty-guarantor" oversight of product potential counterparties. 

CONTRACT APPS support consideration "payment" value dates being . 
"Immediate" (meaning exactly the time at which a contract match 1s 
confirmed); or deferred until a defined time 1n the future, measured In 
terms of seconds, minutes, hours, or days. Similarly, CONTRACT APPS 

15 support entitlement "payment" value dates being "Immediate" (meaning 
exactly the time at which the applicable application promoter formally 
notifies other CONTRACT APP stakeholders of the "result" of a maturing 
contract); or deferred until a defined time after the "result" of a 
maturing contract is known. 

20 CONTRACT APPS allow contracts to be modified and liquidated after 

their creation. Contracts can be modified through: direct negotiation by 
the relevant "risk counterparties" to a particular contract; or the 
purchase/sale of "derivative" secondary risk aversion contract 
transactions (See Process 5 description 1n Appendix C). Contracts can be 

25 similarly liquidated after their creation through sale of the contract 
(within or outside INVENTCO); and through direct negotiation between the 
Initial ordering party and counterparties to the contract. They can also 
be effectively liquidated through the ordering party/counterparty 
acquiring a mirror Image of the contract to which they are a party 

30 (within or outside of INVENTCO). 

Post Order Process Types 

CONTRACT APPS undertake various generic types of 
"post-order-process" management functions for all the above-described 
35 generic types of "transactions", Including: a function which maintains a 
formal record of contractual commitments entered Into by all CONTRACT APP 



WO 94/28496 



PCT/AU93/00250 



-68- 

stakeholders with one another, and with VIRPRO-authorlsed entitles 
external to either the applicable CONTRACT APP or INVENTCO overall ; a 
function which effects the Independent valuation of consideration and 
entitlement obligations between CONTRACT APP stakeholders, and between 

5 CONTRACT APP stakeholders and VIRPRO-authorlsed entitles external to each 
applicable CONTRACT APP; a function which determines and effects 
"col lateral! sat 1 on" consideration/entitlement transfers between CONTRACT 
APP stakeholders, and between CONTRACT APP stakeholders and 
VIRPRO-authorlsed entitles external to each applicable CONTRACT APP, 

10 based on above-described valuations of consideration and entitlement 
obligations associated with CONTRACT APP transactions; a function which 
determines and effects, as required, the b1-lateral netting of 
accumulated "consideration/entitlement" obligations M between CONTRACT 
APP stakeholders, and between CONTRACT APP stakeholders and 

15 VIRPRO-authorlsed entitles external to each applicable CONTRACT APP; a 
function which determines and effects, as required, the multi-lateral 
netting of accumulated "consideration/entitlement" obligations" between 
CONTRACT APP stakeholders, and between CONTRACT APP stakeholders and 
VIRPRO-authorlsed entitles external to each applicable CONTRACT APP 

20 (Involving a nominated third-party "clearing house" entity); a function 
which manages the processing, accounting, reporting, and entitlement 
"payment" tasks associated with maturing contracts; a function which 
determines system usage and access fees payable to/from all CONTRACT APP 
(and other INVENTCO) stakeholders, and to/from VIRPRO-authorlsed entitles 

25 external to INVENTCO; a function which determines and effects, as 
required, "bl -laterally netted" consideration/entitlement transfers 
from/to CONTRACT APP stakeholders themselves, and from/ to CONTRACT APP 
stakeholders and VIRPRO-authorlsed entitles external to each applicable 
CONTRACT APP; a function which determines and effects, as required, 

30 "multi-lateral ly netted" consideration/entitlement transfers from/to 
CONTRACT APP stakeholders themselves, and from/ to CONTRACT APP 
stakeholders and VIRPRO-authorlsed entitles external to each applicable 
CONTRACT APP (Involving a nominated third-party "clearing house" entity); 
and a function which compiles and distributes CONTRACT APP (and other 

35 INVENTCO) stakeholder customised Information. 
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Supplementarv Process Types 

CONTRACT APPS undertake various other types of support processes, 
Including: enabling stakeholders to transfer consideration, entitlement 
and other "payment" obligations to and from one another, Independently of 

5 transfers Initiated by CONTRACT APP transactions (See Process 7 

description In Appendix C); providing CONTRACT APP (and other INVENTCO) 
stakeholders with shared access to specialist systems to assist them to 
decide how best to Interface with the multiple aspects of INVENTCO (See 
Process 8 description 1n Appendix C); and providing CONTRACT APP (and 

10 other INVENTCO) stakeholders with access to a range of 

INVENTCO-facllltated "value added services" (See Process 9 description In 
Appendix C). 

Order Matching Constraint Types 

15 For their operation, CONTRACT APPS require all stakeholders to a 

specific APP to specify, amongst other things, which other stakeholders 
they do and do not want to have Interactions with, and the conditions 
under which they wish to manually authorise some aspect of a transaction 
Involving any other CONTRACT APP stakeholder over which they have control 

20 authority of some form. 

In specifying which other stakeholders they do and do not want to 
have Interactions with, CONTRACT APP stakeholders have various options. 
Application promoters can specify acceptable product sponsors, products, 
ordering parties and potential counterparties within their application - 

25 Individually and by type. Similarly, product sponsors can specify 

acceptable application promoters, products, ordering parties, potential 
counterparties and counterparty-guarantors within their application - 
Individually and by type. 

Product counterparties and ordering parties (collectively) can 

30 specify: ordering parties/potential counterparties they do and do not 
want to deal with - Individually and by type; the extent of their 
preparedness to be Involved In contract netting and collaterallsatlon 
arrangements provided for by their application promoter; application 
promoters, product sponsors, products, and consideration/entitlement 

35 transfer entitles they do and do not want to deal with - individually and 
by type; ordering parties/potential counterparties they prefer to deal 
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wlth, and those with which they wish to deal exclusively; the degree of 
trading transparency they require; and their wish or otherwise to 
manually authorise order matches before they are confirmed. 

Potential counterparties can specify which ordering parties, or 

5 classes of ordering parties, they are prepared to offer credit to (and 
under what terms), and ones they are prepared to allow "ordering 
party-guarantors" to offer credit to and under what terms. Similarly, 
product ordering parties (uniquely) can specify: counterparty-guarantors 
with which they do and do not want to deal (Individually and by type); 

10 counterparties with which they wish to deal exclusively or preferentially 
to obtain a particular form of counterparty-credit; and potential 
"ordering party-guarantors" (external to INVENTCO) with which they do and 
do not want to deal . 

Counterparty-guarantors can specify which potential counterparties 

15 have their authority to operate and which application promoters, product 
sponsors and ordering parties they are prepared, Indirectly, to have 
relationships with. Similarly, regulators can specify which 
counterparty-guarantors, potential counterparties, ordering parties, 
application promoters, product sponsors and products have their authority 

20 to operate. Finally, consideration/entitlement transfer entitles can 
monitor and maintain up-to-date rules with respect to ordering parties, 
counterparties, application promoters, product sponsors, 
counterparty-guarantors, and regulators they are and are not prepared to 
deal with - Individually and by type. 

25 

Ordering Party Requirements 

For their operation, CONTRACT APPS require primary product ordering 
party stakeholders to a CONTRACT APP, In registering an order for a 
product of their choice, to specify: the above-described "product type" 

30 and "other stakeholder Involvement" Information; multiple attributes of 
the specific order they are seeking; their interest or otherwise 1n being 
granted credit by potential counterparties for their contract 
consideration amount, or In availing themselves of the possible netting 
and col lateral 1 sat 1 on features of the APP concerned; the maximum (and 

35 possibly minimum) consideration "price" they are prepared to pay for 
their defined product; and various other dimensions of their needs, where 
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these Include: the name/title by which they wish to be Identified by 
other APP stakeholders; the time at which they wish their order to be 
submitted; the period of time after an order has been submitted that they 
wish the order to be retained before It Is automatically withdrawn; 

5 whether or not they are prepared to accept partial matches of their 
order; the degree of market transparency they wish to be exposed to; 
whether or not they wish wish to have the option of trading a matched 
contract on an authorised INVENTCO secondary market (See Process 5 
description 1n Appendix C>; whether or not they wish to manually 

10 consider/authorise potential counterparty quotes on an order; in the case 
where potential counterparty quotes are required to be manually 
considered/authorised, the maximum time after potential counterparty 
quote details are provided to the ordering party that the ordering party 
wishes to consider the quote(s); and the consideration/entitlement 

15 transfer entity accounts from which/to which they wish to have relevant 
"payments" made/received. 

The above-mentioned multiple attributes of a specific primary order 
an ordering party Is seeking include: their wish or otherwise to directly 
input the entitlement "coordinates" of their desired contingent claim 

20 order; their wish or otherwise to mathematically specify an entitlement 
function reflecting their desired product order, where such functions can 
be single or multidimensional (Indicating a contingent contract 
entitlement conditional on two or more phenomena); the 
"consideration/entitlement unit", "currency" (If applicable), and 

25 "national currency" (If applicable) In which they wish to "payV'recelve" 
their contract consideration/entitlement. Where an ordering party wishes 
to mathematically specify their desired primary product order as a 
single-dimensional entitlement function: the Input term "X" can Indicate 
the number of contract entitlement "inflection points" the ordering party 

30 Is seeking within the allowable range of future product event values 
(Including the value range extremity points); the Input term "Alpha (X) n 
can Indicate the ordering party-sped fled event value corresponding to 
the Xth future product event value contract entitlement Inflection point; 
the input term "Beta (X)" can Indicate the ordering party-specified 

35 desired entitlement amount On the desired "consideration/entitlement 
form", "currency" and "national currency" entitlement denomination) 
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corres ponding to the Xth event value Inflection point; and the Input term 
"Gamma (X-l)" can Indicate the ordering party-specified desired shape of 
the function between each of the co-ordinates: [Alpha (1), Beta (1)] and 
[Alpha (2), Beta (2)] f [Alpha (2), Beta (2)] and [Alpha (3), Beta (3)], 
5 and so on (as applicable), where Gamma can represent all possible, 
mathematically definable, shapes. 

Potential Counterparty Requirements 

For their operation, CONTRACT APPS also require primary product 

10 "potential counterparty" stakeholders to a CONTRACT APP to define various 
parameters on the basis of which they can automatically price orders, 
including parameters with which they wish to establish a "consideration 
bid" on a defined product order; possible Individual contract and product 
constraints they require to be satisfied 1f they were to become a 

15 counterparty to a defined product ordering party order; and possible 

expected-value product-portfolio constraints they require to be satisfied 
if they were to become a counterparty to a defined product ordering party 
order. 

In defining parameters with which they wish to establish a 

20 "consideration bid" on a defined product order under a "EV-CE" pricing 
regime (described above), each potential counterparty Is required to 
specify, amongst other things: an indicator of the appropriate "defined 
circumstances" of all possible product orders; a base "commission rate"; 
a base "discount rate"; (if applicable), a set of base 

25 "consideration/entitlement denomination", "currency" and "national 
currency" exchange rates; base "unit product prices"; and desired 
adjustments to the base commission rate, discount rate, exchange rates, 
and unit product prices on specific product orders according to the 
determined-value of the "defined circumstances" Indicator (based on a 

30 specific product order). 

Possible individual contract and product constraints the potential 
counterparty requires to be satisfied 1f they were to become a 
counterparty to a defined product ordering party order, Include: an 
absolute loss limit constraint (this constraint being specified as a 

35 single-figure constraint and/or as a function constraint); an expected 
loss limit constraint (this constraint defining the maximum "expected" 
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aggregate loss the potential counterparty Is prepared to Incur on a 
contract/product, taking Into account their assessment of the likelihood 
of all feasible future product values occurring); and a constraint on the 
maximum proportion of the expected total loss of the aggregate of the 

5 potential counterparty's contracts/products that can be accounted for by 
the expected loss of the defined Individual contract /product. Similarly, 
possible expected-value product-portfolio constraints the potential 
counterparty requires to be satisfied If they were to become a 
counterparty to a defined product ordering party order include the 

10 maximum (and possibly minimum) proportion of the expected total loss of 
the aggregate of the potential counterparty's product portfolio that can 
be acccounted for by the expected loss of an Individual contract/product. 

Communications 

15 CONTRACT APP stakeholders communicate with their applicable APP via 

AXSC0. Individual n stakeholder- to/from-AXSCO" coiranuni cations can be by 
way of any/all of the following: voice communications with an 
AXSCO-1 inked "live operator" or "recorded messaging" system; 
touch-telephone communication with AXSCO directly; or 

20 computer-to-computer link with AXSCO (via a dedicated or dial-up 

communications line). With all three forms of communication, CONTRACT APP 
stakeholders may be required to utilize specified computer hardware 
and/or software mechanisms in their communications with AXSCO (Including 
"payments" authorisation "black box" devices referred to In Appendix H). 

25 

Component Processes 

In their manifestation as telecommunications/computer software 
residing on telecommunications/computer hardware, individual CONTRACT 
APPS consist of a cluster of processes (detailed 1n Appendix C), 

30 utilizing a number of data files, residing on one or more processing 
units. A cluster of nine (and potentially more or fewer) specific 
processes and their related data files reside within a CONTRACT APP: a 
process handling file administration and updating tasks supporting all 
other processes (termed Process 1); a process handling the receipt and 

35 processing of "primary" risk management contract transactions (termed 
Process 2); a process handling the receipt and processing of "secondary" 
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rlsk management contract transactions (termed Process 3); a process 
handling the receipt and processing of "derivative-primary" risk 
management contract transactions (termed Process 4); a process handling 
the receipt and processing of "derivative-secondary" risk management 

5 contract transactions (termed Process 5); a process handling the "back 
office" management of all four types of risk management contract 
transactions (termed Process 6); a process handling non-transaction 
related consideration, entitlement, and other "payment" obligation 
transfers between stakeholders (termed Process 7); a process handling 

10 CONTRACT APP (and other INVENTCO) stakeholder access to specialist 
systems to assist these stakeholders decide how best to Interface with 
the multiple aspects of INVENTCO (termed Process 8); and a process 
handling CONTRACT APP (and other INVENTCO) stakeholder access to a range 
of INVENTCO-fadlltated "value added services" (termed Process 9). These 

15 processes may function concurrently. 
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APPENDIX C 

DESCRIPTION OF CONTRACT APP PROCESSES 

5 Process 1 

Process 1 handles file administration and updating tasks 
supporting all other processes (Fig. 18). The PRODUCT, PRODUCT TRANS, 
DEAL LIST and DEAL LIST TRANS files referred to 1n Fig. 18 are 
applicable, Individually or collectively, to primary, secondary, 

10 derivative-primary, and derivative-secondary contract orders. The SEL 
PRICE, SEL PRICE TRANS, SEL LIMIT and SEL LIMIT TRANS files are 
applicable only to primary and derivative-primary contract orders. The 

♦ TRADE PRICE, TRADE PRICE TRANS, TRADE LIMIT and TRADE LIMIT TRANS 
files are applicable only to secondary and derivative-secondary 

15 contract orders. 

The file administration and updating tasks handled by Process 1 
comprise: dealing with general data-file Information received from 
CONTRACT APP stakeholders; dealing with general data-file and order 
processing Information received from relevant other INVENTCO 

20 stakeholders, particularly VIRPRO and AXSCO; dealing with trading 
support information received directly from CONTRACT APP stakeholders; 
dealing with potential counterparty primary,- and derivative primary, 
product order "consideration bid" parameters and order-match 
constraints; dealing with exi sting-contract offering party secondary, 

25 and derivative secondary, order match conditions; and dealing with 
miscellaneous Information from entities external to INVENTCO. 

Existing and prospective stakeholders are required to supply 
their applicable CONTRACT APP with specified identification and other 
Information, and to continually maintain the Integrity of this 

30 Information. For each stakeholder, this Information Includes: 

applicable name(s), addresses, contact numbers, and references; their 
desired system access medium; their consideration/entitlement transfer 
entity account details; and, 1f applicable, their required schedule of 
fees and charges payable by other INVENTCO stakeholders. This 

35 Information Is maintained in the data file ADMIN, updated Information 
being received by way of the transaction file ADMIN TRANS. 
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VIRPRO Is required to supply the applicable CONTRACT APP with 
various forms of general data-file information Including: 
Identification data relating to the application promoter for (each) 
CONTRACT APP; details of the permitted types of system access mediums; 

5 and consideration/entitlement denominations available in each 

application. Again, this information Is maintained in the data file 
ADMIN, updated information being received by way of the transaction 
file ADMIN TRANS. 

VIRPRO 1s similarly required to supply the applicable CONTRACT 

10 APP with various forms of general data-file information Including: 
information on all data received by and sent from the various parts of 
INVENTCO to one another and to entities external to INVENTCO; and 
statistical information of various types, Including data traffic 
volumes, data file location Information and so on. This information is 

15 continuously collected by AXSCO and maintained In the data file 
HISTORY. 

Trading support Information received directly from CONTRACT APP 
stakeholders comprises stakeholder relationship Information of a 
general nature, and specific information from individual stakeholders 

20 (detailed in Appendix B). 

Stakeholder relationship information of a general nature 
comprises "transaction communication parameters" and automatic/manual 
deal and no deal flags". Transaction communication parameters are 
parameters set by all (registered) CONTRACT APP stakeholders defining 

25 the bounds within which they wish, for security reasons, all of their 
communications within INVENTCO to fall. Automatic/manual deal and no 
deal flags are "flags" set, as required, by all (registered) CONTRACT 
APP stakeholders Indicating their requirements with respect to dealing 
with other CONTRACT APP stakeholders. This information is maintained 

30 In the data file DEAL LIST, updated Information being received by way 
of the transaction file DEAL LIST TRANS. 

Specific information from Individual stakeholders differs 
according to the category of stakeholder involved. 

Application promoters provide, amongst other things: Information 

35 for the data file, PRODUCT (updated transactions being received from 
the file, PRODUCT TRANS), and further information for the data file 
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ADMIN (updated transactions being received from the file. ADMIN 
TRANS). Information for the data file, PRODUCT includes details of the 
specific products application promoters offer for 
trading/exchange/transfer. Information for the data file, ADMIN 

5 includes: the order pricing and matching process upon which the 
application Is based; the consideration/entitlement "value date" 
regime upon which their application is based; the categories of other 
stakeholders allowed to participate in the application and the 
conditions under which they can do this; the specific rules of 

10 engagement of counterparty-guarantors by potential counterparties; the 
availability and, in turn, the terms and conditions for CONTRACT APP 
stakeholder utilization of "consideration credit", 
"collaterallsation", and "netting" features of the application 
(embodied in the various post-order-processing management routines); 

15 and details of the consideration/entitlement transfer entities 
Involved In the application and relevant security Information 
concerning account access. 

Product sponsors provide full details of the product(s) they are 
sponsoring; product ordering parties and potential counterparties 

20 (collectively) indicate, with respect to each other, the parties they 
either prefer to deal with or wish to deal with exclusively. Potential 
counterparties (exclusively) provide a variety of specific 
Information, Including: details of the Application promoter, Product 
sponsor, and Counterparty-guarantor rules under which they have chosen 

25 to operate; data recording the lines of credit (If any) offered to 
ordering parties and the general and specific terms and conditions of 
these credit lines (applicable to ordering parties Individually and/or 
to defined classes of ordering parties); parameters with which a 
potential counterparty wishes to determine Its consideration "bids" on 

30 orders. Counterparty-guarantors provide details of the potential 
counterparties (if any) they have agreed to guarantee and the nature 
of such guarantees. Regulators provide details of: all entitles having 
a stake In the application and their relationships to one another (for 
example, which counterparty-guarantors cover which counterparties, 

35 which potential counterparties offer which products, and so on); 

specific regulations developed for the regime; and parameters defining 
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the taxation treatment of all types of orders and related 
transactions. Consideration/entitlement transfer entitles provide 
"set-up" and on-going accpunt access and balance-updating services. 
All of the above-described Information Is maintained 1n the data file, 

5 ADMIN, updated information being received by way of the transaction 
file ADMIN TRANS. 

In dealing with potential counterparty primary product order 
"consideration bid" parameters and order-match constraints, potential 
product order counterparties are required, amongst other things, to: 

10 define various parameters with which they wish to establish a 

"consideration bid" on a defined product order; and define parameters 
with which the potential counterparty wishes to determine adjustments 
to the "base-price" bids on product orders according to the specific 
ordering party involved (this Information 1s maintained In the data 

15 file SEL PRICE; updated Information is received by way of the 
transaction files SEL PRICE TRANS); define possible individual 
contract and product constraints the potential counterparty requires 
to be satisfied if they are to become a counterparty to a defined 
product ordering party order; and define possible expected-value 

20 product-portfolio constraints the potential counterparty requires to 
be satisfied if they are to become a counterparty to a defined product 
ordering party order (these latter two categories of information are 
maintained in the data files SEL LIMIT and BUY LIMIT; updated 
information being received by way of the transaction file SEL LIMIT 

25 TRANS) (See Appendix B for further details). 

In dealing with exi sting-contract offering party secondary order 
match conditions, offering parties are required, amongst other things, 
to specify: the Order IDs of the contracts in which the entity 
concerned wishes to "sell" its position as a contract stakeholder, 

30 and, for each such contract, the pricing and other parameters 1t 
requires to be satisfied before a contract position "sale" is 
effected. This information is maintained in the data file TRADE PRICE; 
updated information is received by way of the transaction file TRADE 
PRICE TRANS. 

35 In dealing with potential counterparty derivative-primary 

product order "consideration bid" parameters and order-match 
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constraints, potential product order counterparties are required to 
provide essentially the same information described above in relation 
to primary product orders. However, in addition, information directly 
applicable to the relevant type of derivative-primary transaction 

5 concerned (say, an option to establish a primary product order at a 
later date) is also required. 

In dealing with existing-contract-offerlng party 
derivative-secondary order match conditions, offering parties are 
required to provide essentially the same information described above 

10 In relation to secondary product orders* However, in addition, 
Information directly applicable to the relevant type of 
derivative-secondary transaction concerned (say, an option to sell a 
position in a primary product order at a later date) is also required. 
In dealing with miscellaneous information from entitles external 

15 to INVENTCO, this information can be of any type and may, potentially, 
be used by any part of INVENTCO; the information Is maintained in the 
data-file ADMIN with updated Information being received by way of the 
transaction file ADMIN TRANS 

20 Process 2 

Process 2 handles the receipt and processing of "primary" risk 

management contract transactions (this term being defined In Appendix 

D), such transactions being of multiple types (detailed in Appendix 

B). Various sub-processes of Process 2 handle the receipt and 
25 processing of all possible types of these transactions, including 

product order processing, price quote requests, and withdrawals of 

existing product orders. 

Primary "product orders" constitute the core "primary" risk 

management contract transaction type (Fig. 19 provides a summary flow 
30 chart, and the document text provides a detailed flow chart and 

description of the processing of this transaction type). 

Primary product orders incorporate the following key Items of 

Information: ordering party identification information; CONTRACT APP 

application and product Identification information; "other stakeholder 
35 Involvement" information; the ordering party's desired form of product 

specification (directly input as entitlement coordinates or as 
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mathematlcal functlon(s)); when the order specification 1s by way of a 
single-dimensional mathematical function, the parameters of such a 
function (which can Include: the term "X", the term "Alpha <X>\ the 
term "Beta (X)", the term "Gamma (X-l)"; the contract consideration 

5 and entitlement "denomination type", "currency (1f applicable)" and 
"national currency Of applicable)"; the ordering party's Interest or 
otherwise 1n being granted credit by potential counterparties for the 
yet-to-be-determ1 ned contract consideration amount; the ordering 
party's interest or otherwise in availing themselves of the possible 

10 netting and col lateral Isatlon features of the APP concerned; the 
consideration "price" range within which the ordering party 1s 
prepared to "pay" for their defined product; miscellaneous other 
dimensions of the ordering party's needs, and the 
consideration/entitlement transfer entity accounts from which/to which 

15 they wish to have relevant "payments" made/received). Upon Its 
receipt, all of this Information is written to - and subsequently 
processed from - the file PORD NEW. 

Three sub-processes are involved in processing primary product 
orders - order authorisation, order matching, and matched order 

20 confirmation . In the case of the anticipated most typical form of 
order, termed a "normal -automatic" primary product order these 
sub-processes function as follows: 

The primary product order authorisation sub-process verifies 
that all orders contain data appropriate to the product being sought 

25 and that each ordering party 1s accurately Identified and 

credentialled (this sub-process draws principally on the data-file, 
PPRODUCT). 

The primary product order matching sub-process locates the best 
possible counterpartydes) for the ordering party's transaction 

30 according to the application promoter-spec1f1ed"match1ng rules" 
embodied In the APP; It does this utilizing three component 
sub-processes, termed: short-11 sting of potential -counterparties, 
individual potential -counterparty "pricing" calculations, and 
counterparty selection. 

35 The "short-listing of potential counterparties" sub-process 

component establishes a list of potential counterparties (if any) 
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willing to offer the product sought by the ordering party, upon their 
receipt from the ordering party of a consideration they deem to be 
appropriate (this sub-process draws principally on the data-file, 
PDEAL LIST). 

5 The Individual potential-counterparties pricing calculations 

sub-process component utilises the above-described pricing parameters 
pre-spedf1ed by each short-listed potential counterparty to calculate 
the "bid 11 each of them 1s prepared to make on the orderlng-party's 
product order (or part thereof), and to add these to the potential 

10 counterparties short-list file (this sub-process draws principally on 
the data-file, PSEL PRICE). 

The "counterparty selection" sub-process component extracts from 
the above-described "potential-counterparties short-Ust" file the 
best possible counterparty(ies) for the ordering party's transaction, 

15 according to the application promoter-specified "matching rules" 

embodied in the APP, taking into account whatever matching constraints 
all applicable APP stakeholders may have prespedfied. This selection 
being made, and the price bid being within the allowable limits 
specified by the ordering party, and there being no requirements for 

20 manual -approval intervention by any relevant stakeholder, a matched 
order is deemed to be in existence (this sub-process draws principally 
on the data-file, PSEL LIMIT). 

The matched order confirmation sub-process effectively secures, 
automatically, the positive agreement of all affected stakeholders to 

25 the contract, including confirmation of the product ordering party's 
ability to Immediately pay (or be granted counterparty credit, or 
ordering party guarantor credit, for) the required contract 
consideration (and possible other applicable fees). Automatic 
approvals of contracts are made by the CONTRACT APP electronically 

30 transferring resources recorded 1n the ordering party's applicable 
consideration/entitlement transfer entity account to the account of 
the applicable counterparty (See Appendix H for a description of the 
consideration/entitlement "payment" process). In turn, automatic 
updates of the counterparty's matching constraints maintained In the 

35 file PSEL LIMIT are made. 
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Upon completion of the above-described processing steps: 
unmatched order transactions are written to the file, PORD QUEUE, for 
subsequent match attempts; matched and confirmed order transactions 
are confirmed to the relevant CONTRACT APP stakeholders (this process 

5 drawing principally on the data-file, ADMIN) and are written to the 
file PORD CONF for subsequent "back-office" processing; and relevant 
CONTRACT APP stakeholders are notified of rejected orders (aga1n,th1s 
process drawing principally on the data-file, ADMIN), records of this 
being written to the file PORD REJ for subsequent "back-office" 

10 processing. A copy of all processing outputs 1s written to the file, 
HISTORY. 

Process 3 

Process 3 handles the receipt and processing of "secondary" risk 
15 management contract transactions (this term being defined 1n Appendix 
D). Like "primary" risk management contracts, "secondary" risk 
management contracts are of multiple types (detailed in Appendix B); 
various sub-processes of Process 3 handle the receipt and processing 
of all possible types of these transactions, including product order 
20 processing, product price indications, and withdrawals of existing 
product orders* 

"Secondary product orders" constitute the core "secondary" risk 
management contract transaction type (F1g. 20 provides a summary flow 
chart of the processing of this transaction type). 

25 "Secondary" product orders incorporate the following key Items 

of information: potential acquiring party identification Information; 
the pre-established Order ID reference to the sought-after primary 
contract; the potential acquiring party's interest or otherwise In 
being granted credit by offering parties for the yet- to-be-determined 

30 contract acquisition amount; the acquiring party's Interest or 
otherwise In availing themselves of the possible netting and other 
features of the APP concerned; the acquisition "price" range within 
which the potential acquiring party Is prepared to "pay" for the 
contract they have specified; other dimensions of the potential 

35 acquiring party's needs; and the consideration/entitlement transfer 
entity accounts from which/to which they wish to have relevant 
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"payments" made/received. The above-described Information is, upon 
receipt, written to - and subsequently processed from - the file SORD 
NEW. 

Three sub-processes are involved in processing secondary product 
5 orders -order authorisation, order matching, and matched order 
confirmation. In the case of the anticipated most typical form of 
order, termed a "normal-automatic" secondary product order these 
sub-processes function as follows: 

The secondary product order authorisation sub-process verifies 
10 that all orders contain data appropriate to the contract sought and 
that each potential acquiring party is accurately identified and 
credentialled (this sub-process draws principally on the data-file, 
SPRODUCT) . 

The secondary product order matching sub-process locates 
15 sought-after contract records and, based on the contents of these 
records, determines whether a "sale" of the position of the specified 
stakeholder In the contract to the potential acquiring party Is 
possible - 1n particular, whether the acquisition "price" range within 
which the potential acquiring party has specified it 1s prepared to 
20 "pay" for the position of the specified current stakeholder is equal 
to, or in excess of, the "allowable sale price" figure prespecified by 
the applicable contract stakeholder. If a contract "sale" 1s found to 
be possible, and there being no requirements for manual -approval 
Intervention by any relevant stakeholder, a "match" 1s deemed to have 
25 occurred. 

The secondary product matched order confirmation sub-process 
effectively secures, automatically, the positive agreement of all 
affected stakeholders to the contract position "sale", Including 
confirmation of the contract acquiring party's ability to Immediately 

30 pay (or be granted current stakeholder credit, or acquiring party 
guarantor credit, for) the required "sale price" consideration (and 
possible other applicable fees). Automatic approvals of such "sales" 
are made by the CONTRACT APP electronically transferring resources 
recorded In the acquiring party's applicable consideration/entitlement 

35 transfer entity account to the account of the applicable current 
contract stakeholder. 
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Upon completion of the above-described processing steps: 
unmatched order transactions are written to the file, SORD QUEUE, for 
subsequent match attempts; matched and confirmed order transactions 
are confirmed to the relevant CONTRACT APP stakeholders (this process 

5 drawing principally on the data-file, ADMIN), required records being 
written to the file SORD CONF for further "back-office" processing as 
required; and rejected order transactions are similarly notified to 
the relevant CONTRACT APP stakeholders (again, this process drawing 
principally on the data-file, ADMIN), required records being written 

10 to the file SORD REJ for further"back-off1ce" processing. A copy of 
all processing outputs 1s written to the file, HISTORY. 

Process 4 

Process 4 handles the receipt and processing of 

15 "derivative-primary" risk management contract transactions (this term 
being defined in Appendix D). Like "primary" risk management 
contracts, "derivative-primary" risk management contracts are of 
multiple types (detailed in Appendix B>; various sub-processes of 
Process 4 handle the receipt and processing of all possible types of 

20 these transactions, including product order processing, product price 
Indications, and existing product order withdrawals. 

"Product option orders" Is one Illustrative "derivative-primary" 
risk management contract transaction type (Fig. 21 provides a summary 
flow chart of the processing of this transaction type). 

25 "Derivative-primary" product option orders Incorporate the 

following key Items of information (detailed In Appendix B>: ordering 
party identification Information; CONTRACT APP application and product 
identification Information; "other stakeholder involvement" 
information; the ordering party's desired form of product 

30 specification (directly input as entitlement coordinates or as 

mathematical functlon(s)); when the order specification 1s by way of a 
single-dimensional mathematical function, the parameters of such a 
function (which can Include: the term "X", the term "Alpha (X)\ the 
term "Beta (X)", the term "Gamma (X-l)' 1 ; the contract consideration 

35 and entitlement "denomination type", "currency (if applicable)" and 
"national currency (If applicable)"; the ordering party's Interest or 
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otherwise in being granted credit by potential counterparties for the 
yet-to-be-determined contract option consideration amount; the 
ordering party's Interest or otherwise In availing themselves of the 
possible netting and col lateral Isation features of the APP concerned; 

5 the consideration "price" range within which the ordering party Is 
prepared to "pay" for their defined product option; miscellaneous 
other dimensions of the ordering party's needs, and the 
consideration/entitlement transfer entity accounts from which/to which 
they wish to have relevant "payments" made/received). Upon its 

10 receipt, all of this information 1s written to - and subsequently 
processed from - the file DPORD NEW. 

Three sub-processes are involved 1n processing 
derivative-primary product orders - order authorisation, order 
matching, and matched order confirmation . In the case of the most 

15 likely form of the above-mentioned illustrative option order, termed 
a "normal-automatic" derivative-primary product option order (see 
Appendix 5 for details) these sub-processes function as follows: 
The primary product option order authorisation sub-process 
verifies that all orders contain data appropriate to the product 

20 option being sought and that each ordering party is accurately 

identified and credentlalled (this sub-process draws principally on 
the data-file, DPPRODUCT). 

The primary product option order matching sub-process locates 
the best possible counterparty(les) for the ordering party's 

25 transaction according to the application promoter-specified "matching 
rules" embodied 1n the APP; It does this utilizing three component 
sub-processes, termed: short-listing of potential 
option-counterparties, individual potential option-counterparty 
"pricing" calculations, and option-counterparty selection . 

30 The "short-listing of potential option-counterparties" 

sub-process component establishes a 11st of potential 
option-counterparties (1f any) willing to offer the product option 
sought by the ordering party, upon their receipt from the ordering 
party of an option consideration they deem to be appropriate (this 

35 sub-process draws principally on the data-file, DPDEAL LIST). 
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The "individual potential option-counterparties pricing 
calculations" sub-process component utilises the above-described 
pricing parameters prespecified by each short-listed potential 
option-counterparty to calculate the "bid" each of them Is prepared to 
5 make on the ordering-party's product option order (or part thereof), 
and to add these to the potential option-counterparties short-list 
file (this sub-process draws principally on the data-file, DPSEL 
PRICE). 

The "option-counterparty selection" sub-process component 

10 extracts from the above-described "potential option-counterparties 
short-list" file the best possible counterparty(ies) for the ordering, 
party's transaction, according to the application promoter-specified 
"matching rules" embodied in the APP, taking into account whatever 
matching constraints all applicable APP stakeholders may have 

15 prespecified. This selection being made, and the price bid being 

within the allowable limits specified by the ordering party, and there 
being no requirements for manual-approval Intervention by any relevant 
stakeholder, a matched option order Is deemed to be in existence (this 
sub-process draws principally on the data-file, DPSEL LIMIT). 

20 The matched option order confirmation sub-process effectively 

secures, automatically, the positive agreement of all affected 
stakeholders to the options contract, including confirmation of the 
product-option-ordering party's ability to immediately pay (or be 
granted counterparty credit, or ordering party guarantor credit, for) 

25 the required option product consideration (and possible other 

applicable fees). Automatic approvals of contracts are made by the 
CONTRACT APP electronically transferring resources recorded in the 
ordering party's applicable consideration/entitlement transfer entity 
account to the account of the applicable counterparty (this process 

30 being detailed In Appendix H). In turn, automatic updates of the 
option-counterparty's matching constraints maintained in the file 
DPSEL LIMIT are made. 

Upon completion of the above-described processing steps: 
unmatched option-order transactions are written to the file, DPORD 

35 QUEUE, for subsequent match attempts; matched and confirmed 

option-order transactions are confirmed to the relevant CONTRACT APP 
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stakeholders (this process drawing principally on the data-file, 
ADMIN) and are written to the reference file DP MSTR, and the file 
DPORD CONF for subsequent "back-office" processing; and relevant 
CONTRACT APP stakeholders are notified of rejected orders (again, this 
5 process drawing principally on the data-file, ADMIN), records of this 
being written to the file DPORD REJ for subsequent "back-office" 
processing. A copy of all processing outputs Is written to the file, 
HISTORY. 

If/when an option-holder wishes to exercise Its option over a 
10 pre-established contract, 1t does so by appropriately notifying the 
CONTRACT APP which, 1n turn, retrieves the contract record from 
DPMSTR, effects the necessary additional consideration payments, and 
writes a new record to PORD CONF for subsequent back office 
processing. As described above, the appropriate HISTORY and other 
15 files are updated In this process. 

Process 5 

Process 5 handles the receipt and processing of 
"derivative-secondary" risk management contract transactions (this 

20 term being defined in Appendix D). Like "secondary" risk management 
contracts, "derivative-secondary" risk management contracts are of 
multiple types (detailed in Appendix B); various sub-processes of 
Process 5 handle the receipt and processing of all possible types of 
these transactions, Including product order processing, product price 

25 indications, and withdrawals of existing product orders. 
"Product option orders" is an illustrative 
"derivative-secondary" risk management contract transaction type (Fig. 
22 provides a summary flow chart of the processing of this transaction 
type). 

30 "Derivative-secondary" product option orders incorporate the 

following key items of information: potential acquiring party 
identification information; the pre-established Order ID reference to 
the sought-after primary contract On relation to which an option is 
to be purchased or sold); the potential acquiring party's Interest or 

35 otherwise In being granted credit by offering parties for the 

yet- to-be-determined option contract acquisition amount; the acquiring 
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party's interest or otherwise tn availing Itself of the possible 
netting and other features of the APP concerned; the acquisition 
"price" range within which the potential acquiring party 1s prepared 
to "pay" for the contract option they have specified; other dimensions 

5 of the potential acquiring party's needs; and the 

consideration/entitlement transfer entity accounts from which/to which 
they wish to have relevant "payments" made/received. The 
above-described Information is, upon receipt, written to - and 
subsequently processed from - the file DSORD NEW. 

10 The subprocesses Involved in the processing of 

derivative-secondary product option orders are essentially a 
combination of the processes described above in the case of secondary 
product orders (Process 3) and derivative-primary product option 
orders (Process 4). At the completion of the matching process, matched 

15 orders are written to the reference file DSMSTR and the file DSORD 
CONF for subsequent back office processing. 

If /when an option holder wishes to exercise Its option over a 
pre-established contract, it does so by appropriately notifying the 
CONTRACT APP which, 1n turn, retrieves the contract record from 

20 DSMSTR, effects the necessary additional consideration payments, and 
writes a new record to SORD CONF for subsequent back office 
processing. As described above, the appropriate HISTORY and other 
files are updated in this process. 

25 Process 6 

Process 6 handles the "back office" management of 

"matched/confirmed" primary, secondary, derivative-primary, and 

derivative-secondary risk management contract transactions and 

transactions handled by Processes 7-9. The process Incorporates 
30 multiple sub-processes, collectively accessing multiple data files 

(Fig. 23): primary risk management contract back office processing; 

secondary risk management contract back office processing; 

derivative-primary risk management contract back office processing; 

derivative-secondary risk management contract back office processing; 
35 "Process 7" transactions back office processing; "Process 8" 
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transactlons back office processing; and "Process 9" transactions back 
office processing. 

In relation to the back-office management of confirmed/matched 
primary risk management contracts - a number of sub-processes are 

5 involved, including: Receipt of the previous operating day's 
"matured-contract actual product event value" sub-process; 
"Start-of-day PAYACC management" sub-process; Contract maturity 
management sub-process; Confirmed contract processing sub-process; 
Information compilation and distribution sub-process; Information 

10 extraction from primary orders sub-process; Contract valuation 

sub-process; Contract col lateral Isation payments sub-process; System 
Access and usage fee determination and payments sub-process; Bilateral 
obligations netting sub-process; Multilateral obligations netting 
sub-process; Bilateral payments netting sub-process; Multilateral 

15 payments netting sub-process; and "end-of-day PAYACC management" 
sub-process. 

Receipt of the previous operating day's "matured-contract actual 
product event value" details. This sub-process is flowcharted in Fig. 
24; 1t involves the applicable CONTRACT APP receiving 

20 "matured-contract actual product event value" details from the 
relevant product sponsors (external to INVENTCO). The primary 
data-file, MAT PROD VALUES, is updated with this Information. The 
support data-files, ADMIN, HISTORY, and INFO are similarly updated 
with applicable Information. 

25 "Start-of-day" PAYACC management. This sub-process Is 

flowcharted In Fig. 25; 1t Involves the applicable CONTRACT APP 
receiving consideration/entitlement "actual account" opening-balances 
from participating consideration/entitlement transfer entitles 
(external to INVENTCO) (see Process 7 for details). The primary 

30 data-files, PAYACC SHADOW and PAYACC FINAL are updated with this 
information. The support data-files, HISTORY, INFO and ADMIN, are 
similarly updated with applicable Information. 

Contract maturity management. This subprocess Is flowcharted In 
Fig: 26; it Involves the applicable CONTRACT APP determining and 

35 giving effect to primary and related entitlement-transfers to/from 
applicable CONTRACT APP stakeholders, applicable other INVENTCO 
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stakeholders, where such transfers are principally reflected In 
entries to the data-file, PAYACC SHADOH. CONTRACT APP determines and 
gives effect to these transfers, principally by drawing upon 
product/contract Information maintained 1n the data files, INTREG, MAT 
5 PROD VALUES, COLLAT, CREDIT MGMT, BILAT OBLIG NET, and MULTILAT OBLIG 
NET. These data-files are appropriately updated in the process as are 
the support data-files, ADMIN, HISTORY, TAX/SUB, PAYACC SHADOW and 
INFO. 

Confirmed contract processing. This sub-process, flowcharted 1n 

10 Fig. 27, operates continually throughout each operating day. Details 
of new matched/confirmed contracts are read from the file PORD CONF 
and are then time-stamped and written to the file INTREG as two 
records - one record pertaining to the contract ordering party and the 
other to the contract counterparty. The support data files, INFO, 

15 ADMIN, and HISTORY are appropriately updated in the process. 

Information compilation and distribution. This sub-process, 
flowcharted In Fig. 28, operates continually (beyond a defined 
operating day ), drawing on the data-file INFO. As already described, 
INFO Is updated continually as CONTRACT APP and other INVENTCO events 

20 occur, including pertinent AXSCO message information written In the 
first instance to HISTORY. All relevant INVENTCO stakeholders have 
access to preauthorised parts of INFO. 

Information extraction from primary orders. This sub-process, 
flowcharted In Fig. 29, is effected after the completion of the 

25 defined operating day. Essentially, 1t involves the single task of 
processing the data-file, HISTORY, to yield pertinent information for 
the data-file INFO. One of the most Important items of information 
drawn from HISTORY is (confidential) Information on all of the prior 
day's potential counterparty consideration bid parameters, in 

30 particular the data Items termed "assessed probabilities of 

occurrence". This Information yields "market" information for the 
subsequent contract valuation sub-process. 

Contract valuation. This sub-process, flowcharted in Fig. 30, 
draws principally upon the above-described "markets" information 

35 previously written to INFO. Pertinent data from this file Is "applied 
against" all outstanding contracts maintained 1n INTREG, thereby 
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yielding updated "future product value (FPV)", "expected value" and 
"distribution" value Information for all contracts and. from this, 
revaluations of all future entitlement "expected values" and 
"distribution" values. All these revaluation figures are maintained 1n 
5 INTREG with applicable Information also being written to INFO and 
HISTORY. 

Contract col lateral Isatlon payments. This sub-process, 
flowcharted 1n Fig* 31, draws principally on the data-file INTREG. 
Following the contract valuation process, this col lateral Isatlon 

10 process Involves relevant INTREG records being read and, depending 
(amongst other things) on the precalculated "present value" of the 
expected future entitlement associated with each relevant contract, a 
calculated portion of the present value of the expected future 
consideration amount 1s debited or credited to the PAYACC SHADOW file 

15 of the applicable col lateral Isatlon trustee entity, and the product 
ordering party and/or counterparty as Is applicable. 

Generally, if the most recent precalculated "present value" of 
the expected future entitlement associated with each relevant contract 
Indicates a negative contract value, and If this negative value 

20 exceeds the prior contract valuation figure, the applicable entity's 
trust account 1s credited with the funds difference, with the entity's 
own consideration/entitlement transfer entity account being debited 
correspondingly. If this negative value does not exceed the prior 
contract valuation figure, the applicable entity's trust account is 

25 debited with the funds difference, with the entity's own 

consideration/entitlement transfer entity account being credited 
correspondingly. On the other hand, If the most recent precalculated 
"present value" of the expected future entitlement associated with 
each relevant contract indicates a positive contract value, the only 

30 collateral Isatlon payment adjustment called for Is one In which all 
funds (If any) 1n the applicable entity's trust account are 
transferred to the entity's own consideration/entitlement transfer 
entity account. In each of the above-described cases, a record of all 
entries effected is written to the data-file., COLLAT, and a subset of 

35 this Information Is written to the data-files HISTORY and INFO. 
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System Access and usage fee determination arid payments. This 
subprocess, flowcharted In Fig. 32, deals with the determination and 
payment of system access and usage fees (as distinct from contract 
maturity date fee payments). The function draws principally on the 

5 data-files ADMIN, and HISTORY. Fee payment parameters are maintained 
In data-file ADMIN. These parameters are applied against the day's new 
records already written to HISTORY. Debits and credits for fees so 
determined are written to PAYACC SHADOW with summary Information 
written to INFO and HISTORY. 

10 Bilateral obligations netting. This subprocess, flowcharted 1n 

Fig. 33, effectively maintains an up-to-date matrix of the present 
values of expected future entitlement (and other) obligations between 
pairs of participating ordering parties and counterparties (as well as 
other participating CONTRACT APP and INVENTCO stakeholders), 

15 continually adjusted on the basis of required current consideration, 
entitlement and other payments/receipts as they occur. As required, 
the function updates the above-described matrix in two stages. First, 
with the most recent contract revaluation figures contained within 
INTREG. And second, with the end-of-day payment/receipt amounts 

20 contained within PAYACC SHADOW. Consideration/entitlement transfer 
entity transfers from/to applicable entitles are determined (according 
to the application-promoter specified parameters for so doing) on the 
basis of whether or not any/all of the adjusted bilateral present 
value figures are In excess of their allowable limits. These entries 

25 are written to PAYACC SHADOW, with the data-files BILAT OBLIG NET, 
INTREG, HISTORY, and INFO being subsequently updated. 

Multilateral obligations netting. This subprocess. flowcharted 
In Fig. 34, is essentially the same as the bilateral netting function 
except that a specified "clearing/trustee" entity is effectively 

30 Interposed between all bilateral counterparties and, as such, netted 
obligations are only between the specified "clearing house/trustee" 
entity and each participating entity. 

Bilateral payments netting. This subprocess, flowcharted In 
Fig. 35, Is Independent of the above-described bilateral and 

35 multilateral obligations netting subprocesses. The subprocess operates 
by producing a matrix of bilaterally netted payments/receipts based on 
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records contained in the data-file, PAYACC SHADOW. Single netted 
payment/receipt figures are then rewritten to PAYACC SHADOW, with the 
data-files BILAT PYMTS NET, ADMIN, HISTORY and INFO being subsequently 
updated. 

5 Multilateral payments netting. Like bilateral payments netting, 

this subprocess, flowcharted 1n Fig. 36, Is Independent of the 
above-described bilateral and multilateral obligations netting 
subprocesses. The subprocess operates by producing a matrix of 
bilaterally netted payments/receipts to/from the applicable "clearing 

10 house/trustee" entity based on records contained In the data-file, 
PAYACC SHADOW. Single netted payment/receipt figures (to/from the 
"clearing house/trustee" entity) are then rewritten to PAYACC SHADOW, 
with the data-files MULTILAT PYMTS NET, ADMIN, HISTORY and INFO being 
subsequently updated. 

15 "End-of-day" PAYACC management. This subprocess, flowcharted in 

Fig. 37, Involves a three-stage process. First, the preparation of 
Inter-conslderation/entltlement transfer entity "balancing" 
transactions. Second, the transfer of the final contents of the PAYACC 
SHADOW data-file to the data-file, PAYACC FINAL. And third, the 

20 electronic transmission of the contents of PAYACC FINAL to the 

applicable consideration/entitlement transfer entitles (external to 
INVENTCO). In turn, the subsidiary data-files, ADMIN, HISTORY, and 
INFO are updated. 

25 Process 7 

Process 7 handles non-CONTRACT APP-related obligation transfers 
between applicable INVENTCO stakeholders, that Is, the transfer of 
ownership title over "assets" registered by INVENTCO - typically 
matched/confirmed contracts (recorded as CONTRACT APP INTREG records) 

30 and consideration/entitlement transfer entity resources (recorded as 
PAYACC records). Both of the above-mentioned Items have value to their 
holder. This process enables holders of these Items to assign or lend 
any portion of their holdings to others at their will through 
Initiating the appropriate transactions as NCAROT TRANS. The process 

35 accesses a relatively small number of data files (See Fig. 38). NCAROT 
TRANS received. result In appropriate updates to the primary 
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data-files, PAYACC SHADOW and INTREG. In turn, the subsidiary data 
files t HISTORY, ADMIN and INFO are updated. 
Process 8 

Process B (flowcharted 1n Fig. 39) handles CONTRACT APP (and 

5 other INVENTCO) stakeholder shared-access to specialist systems to 
assist them decide how best to Interface with one or more aspects of 
INVENTCO. In the case of CONTRACT APP stakeholders, the most likely 
users of this process, one collection of such specialist systems are 
termed "decision support systems". The purpose of these systems 1s to 

10 guide a user-stakeholder as to how It should react to/deal with the 
continually changing circumstances within the CONTRACT APP with which 
they are dealing. Different clusters of systems are applicable for 
different CONTRACT APP stakeholders. These systems involve a hierarchy 
of potentially any number of value-added components. 

15 An example of one such system, useful to primary product 

ordering parties, Is a system which helps an ordering party determine 
which of its prespeclfied, but as yet un-matched, orders it should 
withdraw and which of Its potential new product orders It should 
submit. This system Is In the form of a "utility optimization" 

20 mechanism which seeks to identify the best possible composition of 
outstanding orders (and thus, which existing, unmatched orders should 
be withdrawn and which new orders should be submitted) based on two 
things. First, an objective function which seeks to minimize the 
difference between a weighted sum of actual and desired values of a 

25 series of attributes (involving single or multiple products, covering 
the ordering party's "real business exposure" to each product, the 
ordering party's portfolio of contracts which have been "matched" but 
are not yet confirmed, orders which have been submitted but not yet 
matched, and potential yet- to-be-submitted orders (collectively termed 

30 the "buyer's objective portfolio"), these attributes Including, 

amongst other things: the "expected value" of the objective portfolio; 
the "standard deviation" of the objective portfolio; the "Incremental 
cash outflow" attribute of the objective portfolio; the "maximum 
absolute loss" attribute of the objective portfolio; the "expected 

35 loss" attribute of the objective portfolio; the "implied minimum 
return on Investment" of the objective portfolio; and the "Implied 
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expected return on Investment" of the objective portfolio. And second, 
a series of constraints specifying, amongst other things: the required 
"minimum values" of each objective function attribute; and required 
minimum product-shares 1n the ordering party's overall product 

5 portfolio. The mathematical form of this "optimization" could take any 
of a number of alternative forms. 

An optimization mechanism similar to the one described above can 
also aid potential counterparties 1n defining their pricing parameters 
for application against Incoming product orders. 

10 Effectively, systems of the above-described type are 

collectively maintained as a software "library" within the applicable 
CONTRACT APP (although they may also be loaned by VIRPRO-authorlsed 
entitles Independent of INVENTCO and/or acquired by VIRPRO-authorlsed 
parties whether they are INVENTCO stakeholders or not). CONTRACT APP 

15 (and other INVENTCO) stakeholder requests to make use of software 
within this library are received by way of records 1n the file, SSA 
TRANS. These requests result 1n the appropriate records In the file 
SSA being accessed and made available for use via AXSCO and the 
applicable entity's authorised electronic link to INVENTCO. 

20 Appropriate records of the utilization of SSA records are written to 
the data-files HISTORY, ADMIN and INFO. 

Process 9 

Process 9 (flowcharted in Fig. 40) handles CONTRACT APP (and 
25 other INVENTCO) stakeholder shared-access to a range of 

INVENTCO-facilitated value added services. These services can Include: 
accounting, reconciliation, and Information services; value added 
Information reseller services; financial services of multiple types; 
and data processing and telecommunications services. Effectively, 
30 software relating to these services Is maintained as a software 

"library" within the applicable CONTRACT APP (although they may also 
be loaned by VIRPRO-authorlsed entities Independent of INVENTCO and/or 
acquired by VIRPRO-authorlsed parties whether they are INVENTCO 
stakeholders or not ). CONTRACT APP (and other INVENTCO) stakeholder 
35 requests to make use of software within this library are received by 
way of records in the file, VAS TRANS. These requests result in the 
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approprlate records 1n the file VAS being accessed and made available 
for use via AXSCO and the applicable entity's authorised electronic 
link with INVENTCO. Appropriate records of the utilization of VAS 
records are written to the data-files HISTORY, ADMIN and INFO. 
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APPENDIX D 

RISK MANAGEMENT CONTRACTS 

5 Risk management contracts 1s a term used to refer to one type of 

contractual obligation which can be, but does not need to be, 
traded/exchanged/transferred, and subsequently processed and settled, 
using an INVENTCO system. Risk management contracts consist of "primary" 
risk management contracts; "secondary" risk management contracts; 

10 "derivative-primary" risk management contracts; and 

I "derivative-secondary" risk management contracts. 

"Primary" risk management contracts can be "simple" and "complex" 
1n nature ("simple" contracts being derivatives of "complex" contracts). 
A "simple" primary risk management contract Is a tradeable or 

15 untradeable contract conveying an obligation on an entity, upon that 
entity being granted a consideration by another entity (or accepting a 
pledge to be granted a consideration by the other entity), to make an 
entitlement to that other entity depending on the value of a defined 
phenomenon, determined at a defined time 1n the future. 

20 A "complex" primary risk management contract 1s a tradeable or 

untradeable contract conveying an obligation on either or both of two 
entitles, upon one entity [usually] being granted a consideration by the 
other entity (or accepting a pledge to be granted a consideration by the 
other entity), to make an entitlement to pay/receive an entitlement from 

25 one another, depending on the value of a defined phenomenon, determined 
at a defined time 1n the future. A "complex" contract may, In turn, be 
"basic" or "advanced" In nature: a "complex-basic" contract being one 
that does not Involve ordering party and/or matched order counterparty 
"col lateral Isatlon payments" to a third-party trustee or clearing entity 

30 during the life of a contract; and a "complex-advanced" contract being 
one that does Involve ordering party and/or matched order counterparty 
"col lateral Isatlon payments" to a third-party trustee or clearing entity 
during the life of a contract. 

"Secondary" risk management contracts are pre-existing "primary" 

35 risk management contracts. offered for trade (Individually or as a 
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portfollo) by a "risk-counterparty" stakeholder to the underlying 
contract. 

"Derivative-primary" risk management contracts are options 
contracts, or futures contracts, or forward contracts, or forward rate 

5 agreements, or swaps, or like financial Instruments based on specified, 
but yet-to-be-establ1shed, primary risk management contracts. 

"Derivative-secondary" risk management contracts are options 
contracts, or futures contracts, or forward contracts, or forward rate 
agreements, or swaps, or like financial Instruments based on 

10 pre-existing primary risk management contracts (which may have been 
traded since they were first established), Including Instruments based 
on: specified, but yet- to-be established, secondary risk management 
contracts; and the Intended tertiary trading/exchange/transfer of 
specified, established, secondary risk management contracts. 
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APPENDIX H 



PROCESS 2 VARIABLES AND DATA FILES 



5 This Appendix lists the file name and description therefor. 



Order Data Fields 



OID 

10 

BID 
BREF 
PID 
PMAT 
15 PC/ED 
PCUR 
PNCUR 
PPARAM 

20 HAXCONSID 

PAYFUNC 

. PAYPARAM 
25 ACC CONSID 

ACC ENTITL 



30 



RET LIM 



OPRICE 



35 



Unique Identification assigned by CONTRACT APP to every 

new order submitted. 

Ordering party identification. 

Ordering party's own reference for this order. 

Order field specifying the required product. 

Product maturity date. 

Product consideration/entitlement denomination. 

Product currency denomination. 

Product national currency denomination. 

Product specification parameters (eg. minimum value 

(PMIN), maximum value (PMAX) t and the step size (PSTEP)). 

Maximum consideration the ordering party will pay for 

this contract. 

Pay-off function type, contingent on one or more index 
variables. 

Parameters associated with the PAYFUNC. 
The ordering party account the consideration is to be 
paid from. Implied is the account 
consideration/entitlement, currency, national currency. 
The ordering party account the contract entitlement 1s 
to be paid Into. Implied is the account 
consideration/entitlement, currency, national currency. 
Retention time limit for the order, which sets an 
expiration time for the order whilst remaining 
un-matched. 

Price calculated and selected for this order (this value 
will be the matching price). 
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SPRICE 

PAY TRAN 
DCID 
5 OANON 



10 



OMANUAL 



DTID 



Counterparty Identification with which the order was 
matched. 

Payment transaction number. 

Defined circumstances Identification. 

Anonymous flag, set by the ordering party when seeking 

to avoid manual authorisation requests by other 

stakeholders. 

Manual authorisation request flag. If set, the ordering 
party requires manual authorisation before the matched 
order Is fully confirmed. 

Deal type Identification which codes a combination of 
miscellaneous flags such as collateral! sat Ion, bilateral 
and multilateral netting requirements. 



15 Counterparty Short list Arrays 



20 



PRICEFUNC(SID) 



ELFUNC(SID) 



EVFUNC(SID) 

CR(SID) 

25 DR(SID) 

PRICE(SID) 
EL(SID> 

30 AL(SID) 

EV(SID> 

MCC(SID) 

35 



Pricing function: function type and associated 
parameters. 

Expected loss determination function: function type 
and associated parameters. 

Expected value determination function: function type 
and associated parameters, 

Commission rate to be used for the current defined 
circumstances. 

Discount rate to be used for the current defined 
circumstances. 

Price calculated by each counterparty. 

Expected loss calculated for the current order by 

each counterparty. 

Absolute loss calculated for the current order by 
each counterparty. 

Expected values determined for the current order by 
each counterparty. 

Maximum composition any contract (as an expected 
loss) can have of the entire portfolio. 
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MC(SID) 

ELM (SID) 
ELL2(SID) 

5 

ELL3(SID) 

ELL4(SID) 

10 ELL5(SID> 

CEL2(SID) 
CEL3(SID) 

15 CEL4(SID) 

CEL5(SID) 

ALL1 (SID) 
20 ALL2(SID) 
CAL2(SID) 

EVLUSID) 
C-CZEDXCHANG(SID) 

25 



30 



C-CXCHANG(SID) 



C-NCXCHANG(SID) 



35 



Maximum composition the product (as an expected 
loss) can have of the entire portfolio. 
Order expected loss limit- 
Expected loss limits set by the counterparty for the 
product. 

Expected loss limits set by the counterparty for 

equivalent maturity date products. 

Expected loss limits set by the counterparty for 

same month maturity products. 

Expected loss limits set by the counterparty for 

orders In all products. 

Current accumulated expected losses for the product. 
Current accumulated expected losses for equivalent 
maturity date products. 

Current accumulated expected losses for same month 
maturity products. 

Current accumulated expected losses for orders 1n 
all products. 

Absolute loss limit function for each contract. 
Absolute loss limit function set for the product. 
Current absolute limit function accumulated for the 
product. . 

Expected value limit on each order. 
Counterparty consideration/entitlement denomination 
exchange rates which convert the ordering party's 
consideration denomination of ACC CONSID (and 
MAXCONSID) Into the product's consideration 
denomination. 

Counterparty currency exchange rates which covert 
the ordering party's currency of ACC CONSID (and 
MAXCONSID) Into the product's denominated currency. 
Counterparty national currency exchange rates which 
convert the ordering party's national currency of 
ACC CONSID (and MAXCONSID) into the product's 
denominated national currency. 
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10 



E-C/EDXCHANG(SID) Counterparty consideration/entitlement denomination 
exchange rates which convert the ordering party's 
consideration denomination of ACC ENTITLInto the 
product's consideration denomination. 

E-CXCHANG(SID) Counterparty currency exchange rates which covert 

the ordering party's currency of ACC ENTITL Into the 
product's denominated currency. 

E-NCXCHANG(SID) Counterparty national currency exchange rates which 
convert the ordering party's national currency of 
ACC ENTITL Into the product's denominated national 
currency. 



Miscellaneous Variables 



15 BPRICE 
SID 

INDEX 

20 PI 

P2 



Best price selected from the PRICE(SID) array. 
The currently selected or viewed counterparty 
identification. 

Index counter variable required for calculating 
order prices. 

Value calculated by a pricing function at an Index 
point. 

Value calculated by a pay-off function at an Index 
pol ht . 



25 Master Files 



JELLE DESCRIPTION/CONTENTS 

PORD NEW Holds details of all new orders submitted by ordering 

30 parties: 

BID Ordering party Identification. 

BREF Ordering party's own reference for this order, 

PID Order field specifying the required product. 

MAXCONSID Maximum consideration the ordering party will pay for 

35 this contract. 
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10 



15 



PAY FUNG 

PAYPARAM 
ACC CONSID 

ACC C/ED 
ACC CUR 
ACC NCUR 
ACC ENTITL 

RET LIM 



OANON 



OMANUAL 



20 DTID 



Pay-off function type, contingent on one or more Index 
variables. 

Parameters associated with the PAYFUNC. 

The ordering party account the consideration 1s to be 

paid from. 

The ordering party account consideration/entitlement. 

The ordering party account currency. 

The ordering party account national currency. 

The ordering party account the contract entitlement 1s 

to be paid Into. 

Retention time limit for the order, which sets an 
expiration time for the order whilst remaining 
un-matched. 

Anonymous flag, set by the ordering party when seeking 
to avoid manual authorisation requests by other 
stakeholders. 

Manual authorisation request flag. If set, the ordering 
party requires manual authorisation before the matched 
order Is fully confirmed. 

Deal type identification which codes a combination of 
miscellaneous flags such as col lateral 1 sat Ion, bilateral 
and multilateral netting requirements. 



PORD QUEUE This master file holds details of orders which have 
25 already been authorised, and have attempted to match 

once before. Fields as 1n ORD NEW plus some additional 
fields: 

OID Unique Identification assigned by P-CONTRACT to every 

new order submitted. 
30 PMAT Product maturity date. 

C/ED Product consideration/entitlement denomination. 

PCUR Product currency denomination. 

PNCUR Product national currency denomination. 

PPARAM Product specification parameters (eg. minimum value 

35 (PMIN), maximum value (PMAX), and the step size (PSTEP)). 

DCID Defined circumstances Identification. 
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PORD REJ 
ERRCODE 
5 PORD CONF 



OPRICE 
10 SPRICE 
PAY TRAN 
PPRODUCT 

15 

PID 
PMAT 
PC/ED 
PCUR 
20 PNCUR 
PPARAM 



PDEAL LIST 

25 



30 BID 
PID 
SID 
ANON 

35 MANUAL 
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All rejected orders reside 1n this file. Fields as In 

ORD QUEUE plus some additional fields: 

Error code Indicating why the order was rejected. 

When an order 1s matched and fully confirmed, full 
details are stored In this master file. Fields as In ORD 
QUEUE plus some additional fields: 

Price calculated and selected for this order. This value 
will be the matching price. 

Counterparty identification with which the order was 
matched. 

Payment transaction number. 

This master file holds Information (definition details) 
about each product known to the system: 
Product identification. 
Product maturity date. 

Product consideration/entitlement denomination. 

Product currency denomination. 

Product national currency denomination. 

Product specification parameters (eg. minimum value 

(PMIN), maximum value (PMAX), and the step size (PSTEP)). 

This file holds a list of the ordering 

party /product/counterparty tuples of allowable deals to 

occur. Thus by specifying an ordering party (BID) and 

product (PID), a 11st of counterparties who are prepared 

to enter Into a deal with the ordering party /product 

combination, can be obtained: 

Ordering party Identification 

Product Identification 

Counterparty identification 

All stakeholder identifications requiring anonymous 
confirmation. 

All stakeholder Identifications requiring manual 
authorisation 
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PSEL DC 



DCID 
BID 

PAYFUNC 

10 PAYPARAM 
ACC COHSID 

ACC ENTITL 

15 DTID 
PC/ED 
PCUR 
PNCUR 



This file allows counterparties to define 
Identifications for sets of potential order parameters. 
Any order data field can be used to define an order. 
Each defined circumstance identification is then used to 
set unique pricing parameters: 
Defined circumstances Identifications. 
Ordering party Identification 

Pay-off function type, contingent on one or more Index 
variables. 

Parameters associated with the PAYFUNC. 

The ordering part account the consideration is to be 

paid from. 

The ordering party account the contract entitlement is 

to be paid into. 

Deal type Identification. 

Product consideration/entitlement denomination. 

Product currency denomination. 

Product national currency denomination. 



20 PSEL PRICE Contains all counterparty pricing parameters, including 
commission rates, discount rates and exchange rates: 
SID Counterparty Identification - 

PID Product identification 

DCID Defined circumstances Identification 

25 PRICEFUNC Pricing function: function type and associated 
parameters. 

CR Commission rate to be used for the current ordering 

party In the current product. 
DR Discount rate to be used for the current ordering party 

30 In the current product. 



C-C/EDXCHANG Counterparty consideration/entitlement denomination 
exchange rates which convert the ordering party's 
consideration denomination of ACC CONS ID (and MAXCONSID) 
Into the product's consideration denomination. 
35 C-CXCHANG Counterparty currency exchange rates which covert the 
ordering party's currency of ACC CONSID (and MAXCONSID) 
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C-NCXCHANG 



15 



Into the product's denominated currency* 
Counterparty national currency exchange rates which 
convert the ordering party's national currency of ACC 
CONSID (and MAXCONSID) into the product's denominated 
national currency. 
E-C/EDXCHANG Counterparty consideration/entitlement denomination 
exchange rates which convert the ordering party's 
consideration denomination of ACC ENTITL into the 
products consideration denomination. 
E-CXCHANG Counterparty currency exchange rates which covert the 
ordering party's currency of ACC ENTITL into the 
product's denominated currency. 
E-NCXCHANG Counterparty national currency exchange rates which 

convert the ordering party's national currency of ACC 
ENTITL Into the product's denominated national currency. 



PSEL LIMIT 



20 SID 
PID 
DATE 
MCC 



25 



MC 

ELL1 
ELL2 



30 



ELL3 
ELL4 
35 ELLS 



Holds all counterparty portfolio limits and current 
accumulated exposures In the various mathematical forms 
allowed by the system: 
Counterparty Identification 
Product Identification 
Product maturity date. 

Maximum composition any contract (as an expected loss) 
can have of the entire portfolio. 

Maximum composition the product (as an expected loss) 
can have of the entire portfolio. 
Order expected loss limit. 

Expected loss limits set by the counterparty for the 
product. 

Expected loss limits set by the counterparty for 
equivalent maturity date products- 
Expected loss limits set by the counterparty for same 
month maturity products. 

Expected loss limits set by the counterparty for orders 
in all products. 
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CEL2 Current accumulated expected losses for the product. 

CEL3 Current accumulated expected losses for equivalent 

maturity date products. 
CEL4 Current accumulated expected losses for same month 

5 maturity products. 

CEL5 Current accumulated expected losses for orders in all 

products. 

ALL1 Absolute loss limit function for each contract. 

ALL2 Absolute loss limit function set for the product. 

10 CAL2 Current absolute limit function accumulated for the 

product. 

EVL1 Expected value limit on each order. 

PAYACC Payment accounts for all registered stakeholders (inc. 

15 balances and previous SHADOWtransactions), are stored in 
this master file: 

ID Stakeholder Identification. 

NO Account number. 

ACC C/ED The ordering party account consideration/entitlement. 

20 ACC CUR The ordering party account currency. 

ACC NCUR The ordering party account national currency. 

BALANCE Available funds. 

GID Stakeholder identification guaranteeing the account. 
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CLAIMS: 

1. A data processing system to enable the formulation of 
multl -party risk management contracts, the system comprising: 

at least one stakeholder Input means by which ordering 
stakeholders can Input contract data representing at least one offered 
contract 1n at least one predetermined phenomenon, each said phenomenon 
having a range of future outcomes, and said contract data specifying a 
future time of maturity, entitlements due at maturity for the range of 
outcomes, and a consideration due to a counter-party stakeholder; 

at least one counter-party stakeholder input means by which at 
least one counter-party stakeholder can Input registering data as to a 
respective view of the outcomes In said predetermined range of outcomes 
In the future for one or more of said predetermined phenomena; 

a data storage means linked with each said stakeholder Input 
means and linked wHh each said counter-party stakeholder Input means 
to store said contract data and said registering data; and 

data processing means, linked with the data storage means, for 
pricing and matching contracts from said contract data and said 
registering data, said pricing Including selecting the registering data 
corresponding to the time of maturity for each predetermined 
phenomenon, and calculating a counter-consideration derived from said 
entitlements, and said matching Including comparing said consideration 
and said counter-consideration to match an offered contract with at 
least one of said counter-party stakeholders. 

2. The system as In claim 1, further comprising at least one 
other-stakeholder Input means linked with the data storage means, and 
by which phenomena and associated range of outcomes can be Input to be 
stored In the data storage means to be ones of the said predetermined 
phenomena and the predetermined range of outcomes therefor. 

3. The system as 1n claim 2, wherein each other-stakeholder 
Input means 1s configured so that each said predetermined phenomenon 
and associated range of outcomes further Include a predetermined time 
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of maturity, and the said contract data and the said registering data 
are for the predetermined date of maturity. 

4. The system as In claim 2 or claim 3, wherein said 
registering data for each outcome represents a probability of that 
outcome eventuating at the date of maturity, and the said 
counter-consideration Is calculated by elemental multiplication of 
entitlements and the respective probability, all summed over the 
predetermined range, and adjusted at least to calculate the present day 
value thereof. 

5. The system as In claim 4, wherein the said other-stakeholder 
Input means Is configured to receive updating data as to a present day 
outcome of each of the phenomena, 1n turn to be passed to the data 
storage means for recordal . 

6. The system as In claim 5, wherein, on maturity of the 
contract, the data processing means retrieves the updated present day 
outcome of the respective phenomenon from the data storage means, 
determines an entitlement due for that outcome, and passes the 
entitlement to output means of the data processing system for exchange 
of the entitlement between the matched stakeholders. 

7. The system as In claim 6, wherein said output means 1s 
linked with data communications means to remote locations where 
stakeholder accounts reside, and the data processing means causes 
transaction of the entitlement between respective stakeholder accounts. 

8. The system as in claim 4, wherein said other-stakeholder 
Input means receives qualification data which places qualification on 
which of the counter-party registering data can be used to price and/or 
match an offered contract, the said qualification data being stored In 
the data storage means. 

9. The system as In claim 8, wherein said qualification data 1s 
Input to the Input means by parties Including stakeholder guarantors, 
and financial or Institutional regulators. 
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10. The system as In claim 4, wherein the data processing means 
Is configured so that a match of an offered contract 1s made on the 
basis only of a counter-consideration being less than or equal to the 
said consideration. 

11. The system as In claim 10, wherein the data processing means 
1s configured so that a match of an offered contract is made with a 
preferred one of a counter-consideration being less than or equal to 
the said consideration. 

12. The system as 1n claim 4, further comprising a credit record 
and a debit record for each stakeholder held with an exchange 
Institution, the credit records and debit records for exchange of 
entitlements; and the data storage means of the data processing 
apparatus being configured to Include a shadow credit record and a 
shadow debit record for each stakeholder, the data processing means 
being configured to obtain a start-of-day balance for each shadow 
credit record and shadow debit record, and for every transaction 
resulting In an exchange obligation, adjusting the respective shadow 
credit record or shadow debit record, allowing only those transactions 
that do not result 1n the value of the shadow debit record being less 
than the value of the shadow credit record at any time, each said 
adjustment taking place In chronological order, and the data processing 
means further being configured to, at the end-of-day, Instruct ones of 
the exchange Institutions to exchange transacted credits or debits to 
the credit record and debit record of the respective stakeholders In 
accordance with the adjustments of the said permitted transactions, the 
credits and debits be Irrevocable, time Invariant obligations placed on 
the exchange Institutions. 

13.. The system- as In claim 1, wherein, on a match of an offered 
contract, the data processing means passes the matched contract to the 
data storage means for recordal. 
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14. The system as In claim 13, wherein the output means 
generates confirmatory documentation for each stakeholder to a matched 
contract. 

15. A system to enable the formulation of multi-party risk 
management contracts, the system comprising: 

a plurality of main data processing devices interconnected by at 
least one data communications link, each said data processing device 
running an operating system and applications software; 

one or more data storage devices to which each data processing 
device has access; 

a plurality of data Input/output channels providing connection to 
a plurality of stakeholder locations, each said location having data 
processing means, and the system being programmed for: 

regulating Input of data, specifying a risk phenomenon, a 
range of outcomes for the phenomenon, and a time of maturity; 

stakeholders Inputting to a said data storage device by ones 
of the stakeholder data processing locations contract data for an 
offered contract, specifying an entitlement due at maturity for 
each outcome 1n the predetermined range of outcomes for a one of 
the predetermined phenomena, and an amount payable to a seller; 

counter-party stakeholders Inputting to a data storage 
device by ones of the stakeholder data processing locations 
registering data as to a respective view of occurrence of each 
outcome in the predetermined range of outcomes for at least one 
of the predetermined phenomena; 

pricing and matching a contract by the main data processing 
devices for at least one of the offered contracts from the seller 
registered data by: for an offered contract, selecting the 
registering data for the respective phenomenon and, In response 
to entitlements specified for each outcome 1n the range of 
outcomes for the phenomenon, calculating a counter-consideration, 
arid, by comparison of the calculated counter-consideration with 
the consideration, matching an offered contract with at least one 
counter-party s takehol der . 
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16. The system as 1n claim 15, further comprising output means 
for each distributed data processing location whereby, on a match of a 
contract, confirmation 1s output 1n the form of data or documentation 
to respective output means for the matched stakeholders. 

17. A method to enable the formulation of multl -party risk 
management contracts, the method comprising the steps of : 

(a) Inputting Into data processing apparatus, by at least one 
ordering stakeholder Input means thereof, contract data representing at 
least one offered contract In at least one predetermined phenomenon 
having a range of future outcomes, and said contract data specifying a 
future time of maturity, entitlement due at maturity for the range of 
outcomes, and consideration due to a counter-party stakeholder; 

(b) Inputting Into said data processing apparatus, by at least 
one counter-party stakeholder Input means thereof, counter-party 
registering data as to a respective view of each outcome In said 
predetermined range of outcomes 1n the future for one or more of said 
predetermined phenomena; 

(c) storing, In a data storage means of said data processing 
apparatus linked with each said stakeholder Input means and linked with 
each said counter-party stakeholder Input means, said contract data and 
said registering data; and 

(d) pricing and matching at least one of the offered contracts 
by data processing means of the data processing apparatus linked with 
said data storage means, said pricing and matching comprising the 
steps, for each offered contract, of: 

(I) selecting the registering data corresponding to the 
time of maturity for a predetermined phenomenon; 

(II) calculating a counter-consideration derived from the 
said entitlement; 

(III) comparing the said consideration and the said 
counter-consideration; and 

(1v) matching a contract on the basis of said comparison. 



WO 94/28496 



PCT/AU93/00250 



- 146 - 

18. The method as 1n claim 17, comprising the further step, 
before step (a), of: 

(aa) Inputting into said data processing apparatus, by at 
least one other other-stakeholder input means thereof, 
predetermining data of a said phenomenon and an associated range 
of outcomes. 

19. The method as in claim 18, wherein the step (aa) further 
comprises Inputting a predetermined time of maturity for each 
predetermined phenomenon and associated range of outcomes. 

20. The method as 1n claim 19, wherein the registering data for 
each outcome represents a probability of that outcome eventuating at 
the time of maturity, and the step <d)(11) calculating by 

multiplying elemental entitlements for each outcome with the 

respective probabilities; 

summing the products for the predetermined range of outcomes; and 
adjusting the sum at least to calculate a present day value 

thereof to give the counter-party consideration. 

21. The method as in claim 18, comprising the further step 
following step (d) of: 

(e) inputting, by the other-stakeholder input means, data 
representing a present day outcome of each phenomenon. 

22. The method as in claim 21, comprising the further steps, 
following step <e> of, at the time of maturity: 

(f> calculating the entitlement for the updated present 
day outcome; and 

(g> exchanging the entitlement between matched 
stakeholders. 

23. The method as in claim 20, comprising the further steps, 
following step <d>, of: 



WO 94/28496 



FCT7AU93/00250 



- 147 - 

(h) Inputting, by the other-stakeholder Input means, 
qualification data on which of the counter-party registering data 
can be used to price an offered contract. 

24- The method as In claim 20, wherein the step (d)(1v) is 
performed by considering those counter-considerations being only less 
than or equal to the said consideration. 

25. The method as 1n claim 24, wherein the step (d)(1v) is 
performed by matching a preferred one of the counter-considerations 
being less than or equal to the said consideration. 

26. The method as in claim 17, wherein each stakeholder holds a 
credit record and a debit record with an exchange institution, the 
credit record and debit record for exchange of entitlements, the method 
comprising the further steps, following step (d), of: 

(1) creating a shadow credit record and a shadow debit record 
for each stakeholder to be held Independently by the data processing 
apparatus from the exchange Institutions; 

(j) obtaining from each exchange institution a start-of-day 
balance for each shadow credit record and shadow debit record; 

(k) for every translation resulting Vn an exchange obligation, 
the supervisory institution adjusting each respective shadow credit 
record or shadow debit record, allowing only those transactions that do 
not result In the value of the shadow debit record being less than the 
value of the shadow credit record at any time, each said adjustment 
taking place in chronological order; and 

(1) at the end-of-day, the data processing apparatus Instructing 
ones of the exchange institutions to exchange transacted credits or 
debits to the credit record and debit record of the respective 
stakeholders in accordance with the adjustments of the said permitted 
transactions, the credits and debits bei'ng Irrevocable, time Invariant 
obligations placed on the exchange institutions. 
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27. The method as In claim 26, wherein the end-of-day 
Instructions represent credits and debits netted throughout the day for 
each stakeholder In respect of all the transactions of that day. 



28. The method as In claim 17 or claim 18, comprising the 
further step, following step (d) f and before maturity, of: 

<m) a party to a matched contract offering a stake In the 
contract to other parties In exchange for a consideration, and, 
on acceptance of the stake and exchange of the consideration by 
another party, that other party becoming a stakeholder to the 
contract. 



29. The method as In claim 17, comprising the further step 
following step (d) of: 

(n> passing matched contracts to the data storage means 
for recordal . 



30. The method as 1n claim 29, comprising the further step 
following step (n) of: 

<o> generating confirmatory documentation for each 
stakeholder for each matched contract. 



31. A method of making a computer system, the method comprising 
the steps of: 

(a) Interconnecting at least one stakeholder data Input means 
and at least one counter-stakeholder data Input means to data storage 
means; 

(b) Interconnecting the data storage means with data processing 

means; 

(c) Interconnecting the data processing means with output means; 

and 

(d) programming the data processing means to: 

(1) accept stakeholder Input data of contract data 
representing at least one offered contract, each offered contract 



WO 94/28496 



PCT/AU93/00250 



- 149 - 

specifying a predetermined phenomenon, each phenomenon having a 
predetermined range of future outcomes, and each said contract 
data specifying a future time of maturity, an entitlement due for 
each outcome in said range of outcomes, and a consideration 
payable to a counter-party stakeholder; 

(11) accept counter-stakeholder registering data as to a 
respective view of each outcome in said predetermined range of 
outcomes in the future for each one or more of said phenomena; 

(ill) process the contract data and the registering data to 
price and match a contract, the said pricing including: selecting 
the registering data corresponding to the time of maturity for 
each predetermined phenomenon, and calculating a 
counter-consideration derived from the said entitlements; and 
said matching including comparing said consideration and the said 
counter-consideration to match an offered contract with at least 
one of said counter-party stakeholders; and 

(1v) output confirmatory data or documentation for each 
matched contract. 

32. A method of exchanging obligations as between parties, each 
party holding a credit record and a debit record with an exchange 
institution, the credit records and debit records for exchange of 
predetermined obligations, the method comprising the steps of: 

(a) creating a shadow credit record and a shadow debit record 
for each stakeholder party to be held Independently by a supervisory 
institution from the exchange Institutions; 

(b) obtaining from each exchange Institution a start-of-day 
balance for each shadow credit record and shadow debit record; 

<c> for every transaction resulting in an exchange obligation, 
the supervisory Institution adjusting each respective party's shadow 
credit record or shadow debit record, allowing only these transactions 
that do not result in the value of the shadow debit record being less 
than the value of the shadow credit record at any time, each said 
adjustment taking place in chronological order; and 
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(d> at the end-of-day, the supervisory Institution Instructing 

ones of the exchange institutions to exchange credits or debits to the 

credit record and debit record of the respective parties In accordance 

with the adjustments of the said permitted transactions, the credits 

and debits being irrevocable, time Invariant obligations placed on the 
exchange institutions. 

33. The method as in claim 32, wherein the end-of-day 
Instructions represent credits and debits netted throughout the day for 
each party 1n respect of all the transactions of that day. 
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